Slicing And Tiling In Video Coding

ABSTRACT

A video coding mechanism is disclosed. The mechanism includes receiving at a decoder, a bitstream including a video coding layer (VCL) network abstraction layer (NAL) unit containing a slice of image data divided into a plurality of tiles. A number of the tiles in the VCL NAL unit are determined. A number of entry point offsets for the tiles is also determined as one less than the number of the tiles in the VCL NAL unit. Each entry point offset indicates a starting location of a corresponding tile in the VCL NAL unit. The number of entry point offsets is not explicitly signaled in the bitstream. The entry point offsets for the tiles are obtained based on the number of entry point offsets. The tiles are decoded at the entry point offsets to generate a reconstructed image.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of International ApplicationNo. PCT/US2019/051147, filed Sep. 13, 2019 by Ye-Kui Wang, et. al., andtitled “Slicing And Tiling In Video Coding,” which claims the benefit ofU.S. Provisional Patent Application No. 62/731,696, filed Sep. 14, 2018by Ye-Kui Wang, et. al., and titled “Slicing and Tiling In VideoCoding,” which are hereby incorporated by reference.

TECHNICAL FIELD

The present disclosure is generally related to video coding, and isspecifically related to partitioning images into slices, tiles, andcoding tree units (CTUs) to support increased compression in videocoding.

BACKGROUND

The amount of video data needed to depict even a relatively short videocan be substantial, which may result in difficulties when the data is tobe streamed or otherwise communicated across a communications networkwith limited bandwidth capacity. Thus, video data is generallycompressed before being communicated across modern daytelecommunications networks. The size of a video could also be an issuewhen the video is stored on a storage device because memory resourcesmay be limited. Video compression devices often use software and/orhardware at the source to code the video data prior to transmission orstorage, thereby decreasing the quantity of data needed to representdigital video images. The compressed data is then received at thedestination by a video decompression device that decodes the video data.With limited network resources and ever increasing demands of highervideo quality, improved compression and decompression techniques thatimprove compression ratio with little to no sacrifice in image qualityare desirable.

SUMMARY

In an embodiment, the disclosure includes a method implemented in adecoder. The method comprises receiving, by a receiver of the decoder, abitstream including a video coding layer (VCL) network abstraction layer(NAL) unit containing a slice of image data divided into a plurality oftiles. The method further comprises determining, by a processor of thedecoder, a number of the tiles in the VCL NAL unit. The method furthercomprises determining, by the processor, a number of entry point offsetsfor the tiles as one less than the number of the tiles in the VCL NALunit, wherein each entry point offset indicates a starting location of acorresponding tile in the VCL NAL unit, and wherein the number of entrypoint offsets is not explicitly signaled in the bitstream. The methodfurther comprises obtaining, by the processor, the entry point offsetsfor the tiles based on the number of entry point offsets. The methodfurther comprises decoding, by the processor, the tiles at the entrypoint offsets to generate a reconstructed image. In some systems, thenumber of entry point offsets for tiles in a slice is explicitlysignaled. The disclosed system infers the number of entry point offsetsto be one less than the number of tiles. By employing this inference,the number of entry point offsets can be omitted from the bitstream.Accordingly, the bitstream is further condensed. As such, the networkresources used to transmit the bitstream are reduced. Further, memoryresource usage at both the encoder and the decoder is reduced.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the entry point offsets for the tiles areobtained from a slice header associated with the slice.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the bitstream includes a plurality of VCLNAL units, and wherein each VCL NAL unit contains a single slice ofimage data divided into an integer number of tiles. In some systems,slices and tiles are separate division schemes. By requiring slices tobe sub-divided into tiles, information can be inferred. For example,some tile IDs in a slice can be inferred by a first and last tile in theslice. In addition, slice boundaries can be signaled based tile ID andnot relative position of the slice in a frame. This in turn supports anaddressing scheme where slice headers need not be rewritten whensignaling a sub-frame. Accordingly, the bitstream can be furthercondensed in some example, which saves memory resources and networkcommunication resources. Further, the processing resources can be savedat the encoder and/or decoder.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the image data is coded as a plurality ofcoding tree units (CTUs) contained in each of the tiles, and whereinaddresses of the CTUs in the VCL NAL unit are assigned based on tileidentifiers (IDs) corresponding to the tiles. For example, addressingthe CTUs based on tile ID allows addresses to be inferred based on tileID, which may condense the bitstream. Further, tile based addressing forCTUs supports CTUs coding without reference to coding processesoccurring outside the present slice. As such, addressing the CTUs basedon tile ID supports parallel processing, and hence supports increaseddecoding speed at the decoder.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein decoding the tiles includes decoding theCTUs based on addresses of the CTUs in the VCL NAL unit that areexplicitly signaled in the slice header.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein decoding the tiles includes: determining,by the processor, the addresses of the CTUs in the VCL NAL unit based ona tile ID of a first tile contained in the VCL NAL unit; and decoding,by the processor, the CTUs based on the addresses of the CTUs.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the CTUs do not contain a flag indicating alast CTU in the VCL NAL unit, and wherein the VCL NAL unit contains apadding bit immediately following a last CTU in each tile. In somesystems, a flag is employed in each CTU that indicates whether or notthe current CTU is the last CTU in a VCL NAL unit. In the presentdisclosure, the slices and CTUs are addressed based on tile ID, and aVCL NAL unit contains a single slice. Accordingly, the decoder candetermine which CTU is the last CTU in a slice and hence the last CTU inthe VCL NAL unit without such a flag. As a video sequence contains manyframes and a frame contains many CTUs, omitting a bit of data from everyCTU encoding can significantly condense a bitstream. As such, thenetwork resources used to transmit the bitstream are reduced. Further,memory resource usage at both the encoder and the decoder is reduced.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, further comprising forwarding, by the processor,the reconstructed image toward a display as part of a reconstructedvideo sequence.

In an embodiment, the disclosure includes a method implemented in anencoder. The method comprises partitioning, by a processor of theencoder, an image into at least one slice and partitioning the at leastone slice into a plurality of tiles. The method further comprisesencoding, by the processor, the tiles into a bitstream in at least oneVCL NAL unit. The method further comprises encoding, by the processor, anumber of the tiles in the VCL NAL unit in the bitstream. The methodfurther comprises encoding, by the processor, entry point offsets forthe tiles in the bitstream, wherein the entry point offsets eachindicate a starting location of a corresponding tile in the VCL NALunit, and wherein a number of entry point offsets is not explicitlysignaled in the bitstream. The method further comprises transmitting, bya transmitter of the encoder, the bitstream without the number of entrypoint offsets to support decoding the tiles according to an inferencethat the number of entry point offsets for the tiles is one less thanthe number of the tiles in the VCL NAL unit. In some systems, the numberof entry point offsets for tiles in a slice is explicitly signaled. Thedisclosed system infers the number of entry point offsets to be one lessthan the number of tiles. By employing this inference, the number ofentry point offsets can be omitted from the bitstream. Accordingly, thebitstream is further condensed. As such, the network resources used totransmit the bitstream are reduced. Further, memory resource usage atboth the encoder and the decoder is reduced.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the entry point offsets for the tiles areencoded in a slice header associated with the slice.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein bitstream includes a plurality of VCL NALunits, and wherein each VCL NAL unit contains a single slice of theimage divided into an integer number of tiles. In some systems, slicesand tiles are separate division schemes. By requiring slices to besub-divided into tiles, information can be inferred. For example, sometile IDs in a slice can be inferred by a first and last tile in theslice. In addition, slice boundaries can be signaled based tile ID andnot relative position of the slice in a frame. This in turn supports anaddressing scheme where slice headers need not be rewritten whensignaling a sub-frame. Accordingly, the bitstream can be furthercondensed in some example, which saves memory resources and networkcommunication resources. Further, the processing resources can be savedat the encoder and/or decoder.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, partitioning the tiles into a plurality of CTUs;and assigning addresses of the CTUs in the VCL NAL unit based on tileidentifiers (IDs) corresponding to the tiles. For example, addressingthe CTUs based on tile ID allows addresses to be inferred based on tileID, which may condense the bitstream. Further, tile based addressing forCTUs supports CTUs coding without reference to coding processesoccurring outside the present slice. As such, addressing the CTUs basedon tile ID supports parallel processing, and hence supports increaseddecoding speed at the decoder.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, further comprising explicitly signaling, in theslice header, the addresses of the CTUs in the VCL NAL unit.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the addresses of the CTUs in the VCL NALunit are omitted from the bitstream to support a determination of theaddresses of the CTUs at a decoder based on a tile ID of a first tilecontained in the VCL NAL unit. In the present disclosure, the slices andCTUs are addressed based on tile ID, and a VCL NAL unit contains asingle slice. Accordingly, the decoder can determine which CTU is thelast CTU in a slice and hence the last CTU in the VCL NAL unit withoutsuch a flag. As a video sequence contains many frames and a framecontains many CTUs, omitting a bit of data from every CTU encoding cansignificantly condense a bitstream. As such, the network resources usedto transmit the bitstream are reduced. Further, memory resource usage atboth the encoder and the decoder is reduced.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the CTUs do not contain a flag indicating alast CTU in the VCL NAL unit, and wherein the VCL NAL unit contains apadding bit immediately following a last CTU in each tile.

In an embodiment, the disclosure includes a video coding devicecomprising: a processor, a receiver coupled to the processor, and atransmitter coupled to the processor, the processor, receiver, andtransmitter configured to perform the method of any of the precedingaspects.

In an embodiment, the disclosure includes a non-transitory computerreadable medium comprising a computer program product for use by a videocoding device, the computer program product comprising computerexecutable instructions stored on the non-transitory computer readablemedium such that when executed by a processor cause the video codingdevice to perform the method of any of the preceding aspects.

In an embodiment, the disclosure includes a decoder comprising areceiving means for receiving a bitstream including a VCL networkabstraction layer (NAL) unit containing a slice of image data dividedinto a plurality of tiles. The decoder further comprises a determiningmeans for determining a number of the tiles in the VCL NAL unit, anddetermining a number of entry point offsets for the tiles as one lessthan the number of the tiles in the VCL NAL unit, wherein the entrypoint offsets each indicate a starting location of a corresponding tilein the VCL NAL unit, and wherein the number of entry point offsets isnot explicitly signaled in the bitstream. The decoder further comprisesan obtaining means for obtaining the entry point offsets for the tilesbased on the number of entry point offsets. The decoder furthercomprises a decoding means for decoding the tiles at the entry pointoffsets to generate a reconstructed image.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the encoder is further configured toperform the method of any of the preceding aspects.

In an embodiment, the disclosure includes an encoder comprising apartitioning means for partitioning an image into at least one slice andpartitioning the at least one slice into a plurality of tiles. Theencoder further comprises an encoding means for encoding the tiles intoa bitstream in at least one VCL NAL unit, encoding a number of the tilesin the VCL NAL unit in the bitstream, and encoding entry point offsetsfor the tiles in the bitstream, wherein the entry point offsets eachindicate a starting location of a corresponding tile in the VCL NALunit, and wherein a number of entry point offsets is not explicitlysignaled in the bitstream. The encoder further comprises a transmittingmeans for transmitting the bitstream without the number of entry pointoffsets to support decoding the tiles according to an inference that thenumber of entry point offsets for the tiles is one less than the numberof the tiles in the VCL NAL unit.

Optionally, in any of the preceding aspects, another implementation ofthe aspect provides, wherein the encoder is further configured toperform the method of any of the preceding aspects.

For the purpose of clarity, any one of the foregoing embodiments may becombined with any one or more of the other foregoing embodiments tocreate a new embodiment within the scope of the present disclosure.

These and other features will be more clearly understood from thefollowing detailed description taken in conjunction with theaccompanying drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following brief description, taken in connection with theaccompanying drawings and detailed description, wherein like referencenumerals represent like parts.

FIG. 1 is a flowchart of an example method of coding a video signal.

FIG. 2 is a schematic diagram of an example coding and decoding (codec)system for video coding.

FIG. 3 is a schematic diagram illustrating an example video encoder.

FIG. 4 is a schematic diagram illustrating an example video decoder.

FIG. 5 is a schematic diagram illustrating an example bitstreamcontaining an encoded video sequence.

FIG. 6 is a schematic diagram illustrating an example image partitionedfor coding.

FIG. 7 is a schematic diagram of an example video coding device.

FIG. 8 is a flowchart of an example method of encoding an image into abitstream.

FIG. 9 is a flowchart of an example method of decoding an image from abitstream.

FIG. 10 is a schematic diagram of an example system for coding a videosequence of images in a bitstream.

DETAILED DESCRIPTION

It should be understood at the outset that although an illustrativeimplementation of one or more embodiments are provided below, thedisclosed systems and/or methods may be implemented using any number oftechniques, whether currently known or in existence. The disclosureshould in no way be limited to the illustrative implementations,drawings, and techniques illustrated below, including the exemplarydesigns and implementations illustrated and described herein, but may bemodified within the scope of the appended claims along with their fullscope of equivalents.

Many video compression techniques can be employed to reduce the size ofvideo files with minimal loss of data. For example, video compressiontechniques can include performing spatial (e.g., intra-picture)prediction and/or temporal (e.g., inter-picture) prediction to reduce orremove data redundancy in video sequences. For block-based video coding,a video slice (e.g., a video picture or a portion of a video picture)may be partitioned into video blocks, which may also be referred to astreeblocks, coding tree blocks (CTBs), coding tree units (CTUs), codingunits (CUs), and/or coding nodes. Video blocks in an intra-coded (I)slice of a picture are coded using spatial prediction with respect toreference samples in neighboring blocks in the same picture. Videoblocks in an inter-coded unidirectional prediction (P) or bidirectionalprediction (B) slice of a picture may be coded by employing spatialprediction with respect to reference samples in neighboring blocks inthe same picture or temporal prediction with respect to referencesamples in other reference pictures. Pictures may be referred to asframes and/or images, and reference pictures may be referred to asreference frames and/or reference images. Spatial or temporal predictionresults in a predictive block representing an image block. Residual datarepresents pixel differences between the original image block and thepredictive block. Accordingly, an inter-coded block is encoded accordingto a motion vector that points to a block of reference samples formingthe predictive block and the residual data indicating the differencebetween the coded block and the predictive block. An intra-coded blockis encoded according to an intra-coding mode and the residual data. Forfurther compression, the residual data may be transformed from the pixeldomain to a transform domain. These result in residual transformcoefficients, which may be quantized. The quantized transformcoefficients may initially be arranged in a two-dimensional array. Thequantized transform coefficients may be scanned in order to produce aone-dimensional vector of transform coefficients. Entropy coding may beapplied to achieve even more compression. Such video compressiontechniques are discussed in greater detail below.

To ensure an encoded video can be accurately decoded, video is encodedand decoded according to corresponding video coding standards. Videocoding standards include International Telecommunication Union (ITU)Standardization Sector (ITU-T) H.261, International Organization forStandardization/International Electrotechnical Commission (ISO/IEC)Motion Picture Experts Group (MPEG)-1 Part 2, ITU-T H.262 or ISO/IECMPEG-2 Part 2, ITU-T H.263, ISO/IEC MPEG-4 Part 2, Advanced Video Coding(AVC), also known as ITU-T H.264 or ISO/IEC MPEG-4 Part 10, and HighEfficiency Video Coding (HEVC), also known as ITU-T H.265 or MPEG-H Part2. AVC includes extensions such as Scalable Video Coding (SVC),Multiview Video Coding (MVC) and Multiview Video Coding plus Depth(MVC+D), and three dimensional (3D) AVC (3D-AVC). HEVC includesextensions such as Scalable HEVC (SHVC), Multiview HEVC (MV-HEVC), and3D HEVC (3D-HEVC). The joint video experts team (JVET) of ITU-T andISO/IEC has begun developing a video coding standard referred to asVersatile Video Coding (VVC). VVC is included in a Working Draft (WD),which includes JVET-K1001-v4 and JVET-K1002-v1.

In order to code a video image, the image is first partitioned, and thepartitions are coded into a bitstream. Various picture partitioningschemes are available. For example, an image can be partitioned intoregular slices, dependent slices, tiles, and/or according to WavefrontParallel Processing (WPP). For simplicity, HEVC restricts encoders sothat only regular slices, dependent slices, tiles, WPP, and combinationsthereof can be used when partitioning a slice into groups of CTBs forvideo coding. Such partitioning can be applied to support MaximumTransfer Unit (MTU) size matching, parallel processing, and reducedend-to-end delay. MTU denotes the maximum amount of data that can betransmitted in a single packet. If a packet payload is in excess of theMTU, that payload is split into two packets through a process calledfragmentation.

A regular slice, also referred to simply as a slice, is a partitionedportion of an image that can be reconstructed independently from otherregular slices within the same picture, notwithstanding someinterdependencies due to loop filtering operations. Each regular sliceis encapsulated in its own Network Abstraction Layer (NAL) unit fortransmission. Further, in-picture prediction (intra sample prediction,motion information prediction, coding mode prediction) and entropycoding dependency across slice boundaries may be disabled to supportindependent reconstruction. Such independent reconstruction supportsparallelization. For example, regular slice based parallelizationemploys minimal inter-processor or inter-core communication. However, aseach regular slice is independent, each slice is associated with aseparate slice header. The use of regular slices can incur a substantialcoding overhead due to the bit cost of the slice header for each sliceand due to the lack of prediction across the slice boundaries. Further,regular slices may be employed to support matching for MTU sizerequirements. Specifically, as a regular slice is encapsulated in aseparate NAL unit and can be independently coded, each regular sliceshould be smaller than the MTU in MTU schemes to avoid breaking theslice into multiple packets. As such, the goal of parallelization andthe goal of MTU size matching may place contradicting demands to a slicelayout in a picture.

Dependent slices are similar to regular slices, but have shortened sliceheaders and allow partitioning of the image treeblock boundaries withoutbreaking in-picture prediction. Accordingly, dependent slices allow aregular slice to be fragmented into multiple NAL units, which providesreduced end-to-end delay by allowing a part of a regular slice to besent out before the encoding of the entire regular slice is complete.

A tile is a partitioned portion of an image created by horizontal andvertical boundaries that create columns and rows of tiles. Tiles may becoded in raster scan order (right to left and top to bottom). The scanorder of CTBs is local within a tile. Accordingly, CTBs in a first tileare coded in raster scan order, before proceeding to the CTBs in thenext tile. Similar to regular slices, tiles break in-picture predictiondependencies as well as entropy decoding dependencies. However, tilesmay not be included into individual NAL units, and hence tiles may notbe used for MTU size matching. Each tile can be processed by oneprocessor/core, and the inter-processor/inter-core communicationemployed for in-picture prediction between processing units decodingneighboring tiles may be limited to conveying a shared slice header(when adjacent tiles are in the same slice), and performing loopfiltering related sharing of reconstructed samples and metadata. Whenmore than one tile is included in a slice, the entry point byte offsetfor each tile other than the first entry point offset in the slice maybe signaled in the slice header. For each slice and tile, at least oneof the following conditions should be fulfilled: 1) all coded treeblocksin a slice belong to the same tile; and 2) all coded treeblocks in atile belong to the same slice.

In WPP, the image is partitioned into single rows of CTBs. Entropydecoding and prediction mechanisms may use data from CTBs in other rows.Parallel processing is made possible through parallel decoding of CTBrows. For example, a current row may be decoded in parallel with apreceding row. However, decoding of the current row is delayed from thedecoding process of the preceding rows by two CTBs. This delay ensuresthat data related to the CTB above and the CTB above and to the right ofthe current CTB in the current row is available before the current CTBis coded. This approach appears as a wavefront when representedgraphically. This staggered start allows for parallelization with up toas many processors/cores as the image contains CTB rows. Becausein-picture prediction between neighboring treeblock rows within apicture is permitted, the inter-processor/inter-core communication toenable in-picture prediction can be substantial. The WPP partitioningdoes consider NAL unit sizes. Hence, WPP does not support MTU sizematching. However, regular slices can be used in conjunction with WPP,with certain coding overhead, to implement MTU size matching as desired.

Tiles may also include motion constrained tile sets. A motionconstrained tile set (MCTS) is a tile set designed such that associatedmotion vectors are restricted to point to full-sample locations insidethe MCTS and to fractional-sample locations that require onlyfull-sample locations inside the MCTS for interpolation. Further, theusage of motion vector candidates for temporal motion vector predictionderived from blocks outside the MCTS is disallowed. This way, each MCTSmay be independently decoded without the existence of tiles not includedin the MCTS. Temporal MCTSs supplemental enhancement information (SEI)messages may be used to indicate the existence of MCTSs in the bitstreamand signal the MCTSs. The MCTSs SEI message provides supplementalinformation that can be used in the MCTS sub-bitstream extraction(specified as part of the semantics of the SEI message) to generate aconforming bitstream for a MCTS. The information includes a number ofextraction information sets, each defining a number of MCTSs andcontaining raw bytes sequence payload (RBSP) bytes of the replacementvideo parameter sets (VPSs), sequence parameter sets (SPSs), and pictureparameter sets (PPSs) to be used during the MCTS sub-bitstreamextraction process. When extracting a sub-bitstream according to theMCTS sub-bitstream extraction process, parameter sets (VPSs, SPSs, andPPSs) may be rewritten or replaced, and slice headers may updatedbecause one or all of the slice address related syntax elements(including first_slice_segment_in_pic_flag and slice_segment_address)may employ different values in the extracted sub-bitstream.

The preceding tiling and slicing mechanisms provide significantflexibility to support MTU size matching and parallel processing.However, MTU size matching has become less relevant due to the everincreasing speed and reliability of telecommunication networks. Forexample, one of the primary uses of MTU size matching is to supportdisplaying error-concealed pictures. An error-concealed picture is adecoded picture that is created from a transmitted coded picture whenthere is some data loss. Such data loss can include a loss of someslices of a coded picture or errors in reference pictures used by thecoded picture (e.g., the reference picture is also an error-concealedpicture). An error-concealed picture can be created by displaying thecorrect slices and estimating the erroneous slices, for example bycopying a slice corresponding to the erroneous slice from the previouspicture in the video sequence. Error-concealed pictures can be generatedwhen each slice is contained in a single NAL unit. However, if slicesare fragmented over multiple NAL units (e.g., no MTU size matching), theloss of one NAL unit can corrupt multiple slices. Generation oferror-concealed pictures is less relevant in modern network environmentsas packet loss is a much less common occurrence and because modernnetwork speeds allow the system to completely omit pictures with errorswithout causing significant video freezing as the delay between anerroneous picture and a following error-less picture is generally small.Further, the process for estimating the quality of an error-concealedpicture may be complicated, and hence simply omitting the erroneouspicture may be preferable. Consequently, video conversationalapplications, such as video conferencing and video telephony, and evenbroadcast applications generally forgo using error-concealed pictures.

As error-concealed pictures are less useful, MTU size matching is lessuseful. Further, continuing to support MTU size matching paradigms whenpartitioning may unnecessarily complicate coding systems and as well asuse waste bits that could otherwise be omitted to increase codingefficiency. In addition, some tiling schemes (e.g., MCTS) allowsub-pictures of a picture to be displayed. In order to display asub-picture, slices in a region of interest are displayed and otherslices are omitted. The region of interest may begin at a location otherthan the top-left portion of the picture, and may therefore haveaddresses that are offset from the start of the picture by a variablevalue. In order to properly display the sub-image, a splicer may be usedto rewrite the slice header(s) for the region of interest to account forthis offset. A slicing and tiling scheme that did not require such sliceheader rewriting would be beneficial. In addition, tile boundaries maynot be treated as picture boundaries unless they are collocated withpicture boundaries. However, treating tile boundaries as pictureboundaries may increase coding efficiency in some cases due to thepadding of the boundaries and due to relaxing constraints related tomotion vectors that point to samples outside the boundaries in thereference pictures. Also, HEVC may employ a flag named end_of_slice_flagat the end of the coded data for each CTU to indicate whether the end ofthe slice has been reached. AVC employs this flag at the end of thecoded data for each macroblock (MB) for the same purpose. However,coding of this flag is unnecessary and a waste of bits when the lastCTU/MB is known through other mechanisms. The present disclosurepresents mechanisms to address these and other issues in the videocoding arts.

Disclosed herein are various mechanisms to increase the codingefficiency and reduce processing overhead associated with the slicingand tiling schemes discussed above. In an example, slices are requiredto include an integer number of tiles and each slice is stored in aseparate Video Coding Layer (VCL) NAL unit. Further, the number of tilesin a slice can be computed based on the upper left corner tile and thebottom-right corner tile of a slice. The number of tiles can then beemployed to compute other values that can hence be omitted from thebitstream. As a specific example, the address of each tile in abitstream is an entry point offset from the beginning of the slice andhence the beginning of the VCL NAL unit. The number of entry pointoffsets can be computed as one less than the number of tiles (as thefirst tile has an offset of zero and is hence omitted). The number ofentry point offsets can then be used when retrieving the entry pointoffsets for the tiles from a slice header corresponding to the slice. Inaddition, the CTUs in the tiles may be addressed as a function of a tileidentifier (ID) containing the corresponding CTUs. The addresses of theCTUs can then be explicitly signaled or derived, depending on theembodiment, based on the tile IDs and the computed number of tiles.Further, the knowledge of the number of tiles in the VCL NAL unit andthe number of CTUs in the tiles allows a decoder to determine the lastCTU in a VCL NAL unit. Accordingly, the end_of_slice_flag that waspreviously included in each CTU to indicate the last CTU in the slicecan be omitted from the bitstream, which results in a savings of one bitfor each CTU in the entire video sequence. These and other examples aredescribed in detail below.

FIG. 1 is a flowchart of an example operating method 100 of coding avideo signal. Specifically, a video signal is encoded at an encoder. Theencoding process compresses the video signal by employing variousmechanisms to reduce the video file size. A smaller file size allows thecompressed video file to be transmitted toward a user, while reducingassociated bandwidth overhead. The decoder then decodes the compressedvideo file to reconstruct the original video signal for display to anend user. The decoding process generally mirrors the encoding process toallow the decoder to consistently reconstruct the video signal.

At step 101, the video signal is input into the encoder. For example,the video signal may be an uncompressed video file stored in memory. Asanother example, the video file may be captured by a video capturedevice, such as a video camera, and encoded to support live streaming ofthe video. The video file may include both an audio component and avideo component. The video component contains a series of image framesthat, when viewed in a sequence, gives the visual impression of motion.The frames contain pixels that are expressed in terms of light, referredto herein as luma components (or luma samples), and color, which isreferred to as chroma components (or color samples). In some examples,the frames may also contain depth values to support three dimensionalviewing.

At step 103, the video is partitioned into blocks. Partitioning includessubdividing the pixels in each frame into square and/or rectangularblocks for compression. For example, in High Efficiency Video Coding(HEVC) (also known as H.265 and MPEG-H Part 2) the frame can first bedivided into coding tree units (CTUs), which are blocks of a predefinedsize (e.g., sixty-four pixels by sixty-four pixels). The CTUs containboth luma and chroma samples. Coding trees may be employed to divide theCTUs into blocks and then recursively subdivide the blocks untilconfigurations are achieved that support further encoding. For example,luma components of a frame may be subdivided until the individual blockscontain relatively homogenous lighting values. Further, chromacomponents of a frame may be subdivided until the individual blockscontain relatively homogenous color values. Accordingly, partitioningmechanisms vary depending on the content of the video frames.

At step 105, various compression mechanisms are employed to compress theimage blocks partitioned at step 103. For example, inter-predictionand/or intra-prediction may be employed. Inter-prediction is designed totake advantage of the fact that objects in a common scene tend to appearin successive frames. Accordingly, a block depicting an object in areference frame need not be repeatedly described in adjacent frames.Specifically, an object, such as a table, may remain in a constantposition over multiple frames. Hence the table is described once andadjacent frames can refer back to the reference frame. Pattern matchingmechanisms may be employed to match objects over multiple frames.Further, moving objects may be represented across multiple frames, forexample due to object movement or camera movement. As a particularexample, a video may show an automobile that moves across the screenover multiple frames. Motion vectors can be employed to describe suchmovement. A motion vector is a two-dimensional vector that provides anoffset from the coordinates of an object in a frame to the coordinatesof the object in a reference frame. As such, inter-prediction can encodean image block in a current frame as a set of motion vectors indicatingan offset from a corresponding block in a reference frame.

Intra-prediction encodes blocks in a common frame. Intra-predictiontakes advantage of the fact that luma and chroma components tend tocluster in a frame. For example, a patch of green in a portion of a treetends to be positioned adjacent to similar patches of green.Intra-prediction employs multiple directional prediction modes (e.g.,thirty-three in HEVC), a planar mode, and a direct current (DC) mode.The directional modes indicate that a current block is similar/the sameas samples of a neighbor block in a corresponding direction. Planar modeindicates that a series of blocks along a row/column (e.g., a plane) canbe interpolated based on neighbor blocks at the edges of the row. Planarmode, in effect, indicates a smooth transition of light/color across arow/column by employing a relatively constant slope in changing values.DC mode is employed for boundary smoothing and indicates that a block issimilar/the same as an average value associated with samples of all theneighbor blocks associated with the angular directions of thedirectional prediction modes. Accordingly, intra-prediction blocks canrepresent image blocks as various relational prediction mode valuesinstead of the actual values. Further, inter-prediction blocks canrepresent image blocks as motion vector values instead of the actualvalues. In either case, the prediction blocks may not exactly representthe image blocks in some cases. Any differences are stored in residualblocks. Transforms may be applied to the residual blocks to furthercompress the file.

At step 107, various filtering techniques may be applied. In HEVC, thefilters are applied according to an in-loop filtering scheme. The blockbased prediction discussed above may result in the creation of blockyimages at the decoder. Further, the block based prediction scheme mayencode a block and then reconstruct the encoded block for later use as areference block. The in-loop filtering scheme iteratively applies noisesuppression filters, de-blocking filters, adaptive loop filters, andsample adaptive offset (SAO) filters to the blocks/frames. These filtersmitigate such blocking artifacts so that the encoded file can beaccurately reconstructed. Further, these filters mitigate artifacts inthe reconstructed reference blocks so that artifacts are less likely tocreate additional artifacts in subsequent blocks that are encoded basedon the reconstructed reference blocks.

Once the video signal has been partitioned, compressed, and filtered,the resulting data is encoded in a bitstream at step 109. The bitstreamincludes the data discussed above as well as any signaling data desiredto support proper video signal reconstruction at the decoder. Forexample, such data may include partition data, prediction data, residualblocks, and various flags providing coding instructions to the decoder.The bitstream may be stored in memory for transmission toward a decoderupon request. The bitstream may also be broadcast and/or multicasttoward a plurality of decoders. The creation of the bitstream is aniterative process. Accordingly, steps 101, 103, 105, 107, and 109 mayoccur continuously and/or simultaneously over many frames and blocks.The order shown in FIG. 1 is presented for clarity and ease ofdiscussion, and is not intended to limit the video coding process to aparticular order.

The decoder receives the bitstream and begins the decoding process atstep 111. Specifically, the decoder employs an entropy decoding schemeto convert the bitstream into corresponding syntax and video data. Thedecoder employs the syntax data from the bitstream to determine thepartitions for the frames at step 111. The partitioning should match theresults of block partitioning at step 103. Entropy encoding/decoding asemployed in step 111 is now described. The encoder makes many choicesduring the compression process, such as selecting block partitioningschemes from several possible choices based on the spatial positioningof values in the input image(s). Signaling the exact choices may employa large number of bins. As used herein, a bin is a binary value that istreated as a variable (e.g., a bit value that may vary depending oncontext). Entropy coding allows the encoder to discard any options thatare clearly not viable for a particular case, leaving a set of allowableoptions. Each allowable option is then assigned a code word. The lengthof the code words is based on the number of allowable options (e.g., onebin for two options, two bins for three to four options, etc.) Theencoder then encodes the code word for the selected option. This schemereduces the size of the code words as the code words are as big asdesired to uniquely indicate a selection from a small sub-set ofallowable options as opposed to uniquely indicating the selection from apotentially large set of all possible options. The decoder then decodesthe selection by determining the set of allowable options in a similarmanner to the encoder. By determining the set of allowable options, thedecoder can read the code word and determine the selection made by theencoder.

At step 113, the decoder performs block decoding. Specifically, thedecoder employs reverse transforms to generate residual blocks. Then thedecoder employs the residual blocks and corresponding prediction blocksto reconstruct the image blocks according to the partitioning. Theprediction blocks may include both intra-prediction blocks andinter-prediction blocks as generated at the encoder at step 105. Thereconstructed image blocks are then positioned into frames of areconstructed video signal according to the partitioning data determinedat step 111. Syntax for step 113 may also be signaled in the bitstreamvia entropy coding as discussed above.

At step 115, filtering is performed on the frames of the reconstructedvideo signal in a manner similar to step 107 at the encoder. Forexample, noise suppression filters, de-blocking filters, adaptive loopfilters, and SAO filters may be applied to the frames to remove blockingartifacts. Once the frames are filtered, the video signal can be outputto a display at step 117 for viewing by an end user.

FIG. 2 is a schematic diagram of an example coding and decoding (codec)system 200 for video coding. Specifically, codec system 200 providesfunctionality to support the implementation of operating method 100.Codec system 200 is generalized to depict components employed in both anencoder and a decoder. Codec system 200 receives and partitions a videosignal as discussed with respect to steps 101 and 103 in operatingmethod 100, which results in a partitioned video signal 201. Codecsystem 200 then compresses the partitioned video signal 201 into a codedbitstream when acting as an encoder as discussed with respect to steps105, 107, and 109 in method 100. When acting as a decoder codec system200 generates an output video signal from the bitstream as discussedwith respect to steps 111, 113, 115, and 117 in operating method 100.The codec system 200 includes a general coder control component 211, atransform scaling and quantization component 213, an intra-pictureestimation component 215, an intra-picture prediction component 217, amotion compensation component 219, a motion estimation component 221, ascaling and inverse transform component 229, a filter control analysiscomponent 227, an in-loop filters component 225, a decoded picturebuffer component 223, and a header formatting and context adaptivebinary arithmetic coding (CABAC) component 231. Such components arecoupled as shown. In FIG. 2, black lines indicate movement of data to beencoded/decoded while dashed lines indicate movement of control datathat controls the operation of other components. The components of codecsystem 200 may all be present in the encoder. The decoder may include asubset of the components of codec system 200. For example, the decodermay include the intra-picture prediction component 217, the motioncompensation component 219, the scaling and inverse transform component229, the in-loop filters component 225, and the decoded picture buffercomponent 223. These components are now described.

The partitioned video signal 201 is a captured video sequence that hasbeen partitioned into blocks of pixels by a coding tree. A coding treeemploys various split modes to subdivide a block of pixels into smallerblocks of pixels. These blocks can then be further subdivided intosmaller blocks. The blocks may be referred to as nodes on the codingtree. Larger parent nodes are split into smaller child nodes. The numberof times a node is subdivided is referred to as the depth of thenode/coding tree. The divided blocks can be included in coding units(CUs) in some cases. For example, a CU can be a sub-portion of a CTUthat contains a luma block, red difference chroma (Cr) block(s), and ablue difference chroma (Cb) block(s) along with corresponding syntaxinstructions for the CU. The split modes may include a binary tree (BT),triple tree (TT), and a quad tree (QT) employed to partition a node intotwo, three, or four child nodes, respectively, of varying shapesdepending on the split modes employed. The partitioned video signal 201is forwarded to the general coder control component 211, the transformscaling and quantization component 213, the intra-picture estimationcomponent 215, the filter control analysis component 227, and the motionestimation component 221 for compression.

The general coder control component 211 is configured to make decisionsrelated to coding of the images of the video sequence into the bitstreamaccording to application constraints. For example, the general codercontrol component 211 manages optimization of bitrate/bitstream sizeversus reconstruction quality. Such decisions may be made based onstorage space/bandwidth availability and image resolution requests. Thegeneral coder control component 211 also manages buffer utilization inlight of transmission speed to mitigate buffer underrun and overrunissues. To manage these issues, the general coder control component 211manages partitioning, prediction, and filtering by the other components.For example, the general coder control component 211 may dynamicallyincrease compression complexity to increase resolution and increasebandwidth usage or decrease compression complexity to decreaseresolution and bandwidth usage. Hence, the general coder controlcomponent 211 controls the other components of codec system 200 tobalance video signal reconstruction quality with bit rate concerns. Thegeneral coder control component 211 creates control data, which controlsthe operation of the other components. The control data is alsoforwarded to the header formatting and CABAC component 231 to be encodedin the bitstream to signal parameters for decoding at the decoder.

The partitioned video signal 201 is also sent to the motion estimationcomponent 221 and the motion compensation component 219 forinter-prediction. A frame or slice of the partitioned video signal 201may be divided into multiple video blocks. Motion estimation component221 and the motion compensation component 219 perform inter-predictivecoding of the received video block relative to one or more blocks in oneor more reference frames to provide temporal prediction. Codec system200 may perform multiple coding passes, e.g., to select an appropriatecoding mode for each block of video data.

Motion estimation component 221 and motion compensation component 219may be highly integrated, but are illustrated separately for conceptualpurposes. Motion estimation, performed by motion estimation component221, is the process of generating motion vectors, which estimate motionfor video blocks. A motion vector, for example, may indicate thedisplacement of a coded object relative to a predictive block. Apredictive block is a block that is found to closely match the block tobe coded, in terms of pixel difference. A predictive block may also bereferred to as a reference block. Such pixel difference may bedetermined by sum of absolute difference (SAD), sum of square difference(SSD), or other difference metrics. HEVC employs several coded objectsincluding a CTU, coding tree blocks (CTBs), and CUs. For example, a CTUcan be divided into CTBs, which can then be divided into CBs forinclusion in CUs. A CU can be encoded as a prediction unit (PU)containing prediction data and/or a transform unit (TU) containingtransformed residual data for the CU. The motion estimation component221 generates motion vectors, PUs, and TUs by using a rate-distortionanalysis as part of a rate distortion optimization process. For example,the motion estimation component 221 may determine multiple referenceblocks, multiple motion vectors, etc. for a current block/frame, and mayselect the reference blocks, motion vectors, etc. having the bestrate-distortion characteristics. The best rate-distortioncharacteristics balance both quality of video reconstruction (e.g.,amount of data loss by compression) with coding efficiency (e.g., sizeof the final encoding).

In some examples, codec system 200 may calculate values for sub-integerpixel positions of reference pictures stored in decoded picture buffercomponent 223. For example, video codec system 200 may interpolatevalues of one-quarter pixel positions, one-eighth pixel positions, orother fractional pixel positions of the reference picture. Therefore,motion estimation component 221 may perform a motion search relative tothe full pixel positions and fractional pixel positions and output amotion vector with fractional pixel precision. The motion estimationcomponent 221 calculates a motion vector for a PU of a video block in aninter-coded slice by comparing the position of the PU to the position ofa predictive block of a reference picture. Motion estimation component221 outputs the calculated motion vector as motion data to headerformatting and CABAC component 231 for encoding and motion to the motioncompensation component 219.

Motion compensation, performed by motion compensation component 219, mayinvolve fetching or generating the predictive block based on the motionvector determined by motion estimation component 221. Again, motionestimation component 221 and motion compensation component 219 may befunctionally integrated, in some examples. Upon receiving the motionvector for the PU of the current video block, motion compensationcomponent 219 may locate the predictive block to which the motion vectorpoints. A residual video block is then formed by subtracting pixelvalues of the predictive block from the pixel values of the currentvideo block being coded, forming pixel difference values. In general,motion estimation component 221 performs motion estimation relative toluma components, and motion compensation component 219 uses motionvectors calculated based on the luma components for both chromacomponents and luma components. The predictive block and residual blockare forwarded to transform scaling and quantization component 213.

The partitioned video signal 201 is also sent to intra-pictureestimation component 215 and intra-picture prediction component 217. Aswith motion estimation component 221 and motion compensation component219, intra-picture estimation component 215 and intra-picture predictioncomponent 217 may be highly integrated, but are illustrated separatelyfor conceptual purposes. The intra-picture estimation component 215 andintra-picture prediction component 217 intra-predict a current blockrelative to blocks in a current frame, as an alternative to theinter-prediction performed by motion estimation component 221 and motioncompensation component 219 between frames, as described above. Inparticular, the intra-picture estimation component 215 determines anintra-prediction mode to use to encode a current block. In someexamples, intra-picture estimation component 215 selects an appropriateintra-prediction mode to encode a current block from multiple testedintra-prediction modes. The selected intra-prediction modes are thenforwarded to the header formatting and CABAC component 231 for encoding.

For example, the intra-picture estimation component 215 calculatesrate-distortion values using a rate-distortion analysis for the varioustested intra-prediction modes, and selects the intra-prediction modehaving the best rate-distortion characteristics among the tested modes.Rate-distortion analysis generally determines an amount of distortion(or error) between an encoded block and an original unencoded block thatwas encoded to produce the encoded block, as well as a bitrate (e.g., anumber of bits) used to produce the encoded block. The intra-pictureestimation component 215 calculates ratios from the distortions andrates for the various encoded blocks to determine which intra-predictionmode exhibits the best rate-distortion value for the block. In addition,intra-picture estimation component 215 may be configured to code depthblocks of a depth map using a depth modeling mode (DMM) based onrate-distortion optimization (RDO).

The intra-picture prediction component 217 may generate a residual blockfrom the predictive block based on the selected intra-prediction modesdetermined by intra-picture estimation component 215 when implemented onan encoder or read the residual block from the bitstream whenimplemented on a decoder. The residual block includes the difference invalues between the predictive block and the original block, representedas a matrix. The residual block is then forwarded to the transformscaling and quantization component 213. The intra-picture estimationcomponent 215 and the intra-picture prediction component 217 may operateon both luma and chroma components.

The transform scaling and quantization component 213 is configured tofurther compress the residual block. The transform scaling andquantization component 213 applies a transform, such as a discretecosine transform (DCT), a discrete sine transform (DST), or aconceptually similar transform, to the residual block, producing a videoblock comprising residual transform coefficient values. Wavelettransforms, integer transforms, sub-band transforms or other types oftransforms could also be used. The transform may convert the residualinformation from a pixel value domain to a transform domain, such as afrequency domain. The transform scaling and quantization component 213is also configured to scale the transformed residual information, forexample based on frequency. Such scaling involves applying a scalefactor to the residual information so that different frequencyinformation is quantized at different granularities, which may affectfinal visual quality of the reconstructed video. The transform scalingand quantization component 213 is also configured to quantize thetransform coefficients to further reduce bit rate. The quantizationprocess may reduce the bit depth associated with some or all of thecoefficients. The degree of quantization may be modified by adjusting aquantization parameter. In some examples, the transform scaling andquantization component 213 may then perform a scan of the matrixincluding the quantized transform coefficients. The quantized transformcoefficients are forwarded to the header formatting and CABAC component231 to be encoded in the bitstream.

The scaling and inverse transform component 229 applies a reverseoperation of the transform scaling and quantization component 213 tosupport motion estimation. The scaling and inverse transform component229 applies inverse scaling, transformation, and/or quantization toreconstruct the residual block in the pixel domain, e.g., for later useas a reference block which may become a predictive block for anothercurrent block. The motion estimation component 221 and/or motioncompensation component 219 may calculate a reference block by adding theresidual block back to a corresponding predictive block for use inmotion estimation of a later block/frame. Filters are applied to thereconstructed reference blocks to mitigate artifacts created duringscaling, quantization, and transform. Such artifacts could otherwisecause inaccurate prediction (and create additional artifacts) whensubsequent blocks are predicted.

The filter control analysis component 227 and the in-loop filterscomponent 225 apply the filters to the residual blocks and/or toreconstructed image blocks. For example, the transformed residual blockfrom the scaling and inverse transform component 229 may be combinedwith a corresponding prediction block from intra-picture predictioncomponent 217 and/or motion compensation component 219 to reconstructthe original image block. The filters may then be applied to thereconstructed image block. In some examples, the filters may instead beapplied to the residual blocks. As with other components in FIG. 2, thefilter control analysis component 227 and the in-loop filters component225 are highly integrated and may be implemented together, but aredepicted separately for conceptual purposes. Filters applied to thereconstructed reference blocks are applied to particular spatial regionsand include multiple parameters to adjust how such filters are applied.The filter control analysis component 227 analyzes the reconstructedreference blocks to determine where such filters should be applied andsets corresponding parameters. Such data is forwarded to the headerformatting and CABAC component 231 as filter control data for encoding.The in-loop filters component 225 applies such filters based on thefilter control data. The filters may include a deblocking filter, anoise suppression filter, a SAO filter, and an adaptive loop filter.Such filters may be applied in the spatial/pixel domain (e.g., on areconstructed pixel block) or in the frequency domain, depending on theexample.

When operating as an encoder, the filtered reconstructed image block,residual block, and/or prediction block are stored in the decodedpicture buffer component 223 for later use in motion estimation asdiscussed above. When operating as a decoder, the decoded picture buffercomponent 223 stores and forwards the reconstructed and filtered blockstoward a display as part of an output video signal. The decoded picturebuffer component 223 may be any memory device capable of storingprediction blocks, residual blocks, and/or reconstructed image blocks.

The header formatting and CABAC component 231 receives the data from thevarious components of codec system 200 and encodes such data into acoded bitstream for transmission toward a decoder. Specifically, theheader formatting and CABAC component 231 generates various headers toencode control data, such as general control data and filter controldata. Further, prediction data, including intra-prediction and motiondata, as well as residual data in the form of quantized transformcoefficient data are all encoded in the bitstream. The final bitstreamincludes all information desired by the decoder to reconstruct theoriginal partitioned video signal 201. Such information may also includeintra-prediction mode index tables (also referred to as codeword mappingtables), definitions of encoding contexts for various blocks,indications of most probable intra-prediction modes, an indication ofpartition information, etc. Such data may be encoded by employingentropy coding. For example, the information may be encoded by employingcontext adaptive variable length coding (CAVLC), CABAC, syntax-basedcontext-adaptive binary arithmetic coding (SBAC), probability intervalpartitioning entropy (PIPE) coding, or another entropy coding technique.Following the entropy coding, the coded bitstream may be transmitted toanother device (e.g., a video decoder) or archived for latertransmission or retrieval.

FIG. 3 is a block diagram illustrating an example video encoder 300.Video encoder 300 may be employed to implement the encoding functions ofcodec system 200 and/or implement steps 101, 103, 105, 107, and/or 109of operating method 100. Encoder 300 partitions an input video signal,resulting in a partitioned video signal 301, which is substantiallysimilar to the partitioned video signal 201. The partitioned videosignal 301 is then compressed and encoded into a bitstream by componentsof encoder 300.

Specifically, the partitioned video signal 301 is forwarded to anintra-picture prediction component 317 for intra-prediction. Theintra-picture prediction component 317 may be substantially similar tointra-picture estimation component 215 and intra-picture predictioncomponent 217. The partitioned video signal 301 is also forwarded to amotion compensation component 321 for inter-prediction based onreference blocks in a decoded picture buffer component 323. The motioncompensation component 321 may be substantially similar to motionestimation component 221 and motion compensation component 219. Theprediction blocks and residual blocks from the intra-picture predictioncomponent 317 and the motion compensation component 321 are forwarded toa transform and quantization component 313 for transform andquantization of the residual blocks. The transform and quantizationcomponent 313 may be substantially similar to the transform scaling andquantization component 213. The transformed and quantized residualblocks and the corresponding prediction blocks (along with associatedcontrol data) are forwarded to an entropy coding component 331 forcoding into a bitstream. The entropy coding component 331 may besubstantially similar to the header formatting and CABAC component 231.

The transformed and quantized residual blocks and/or the correspondingprediction blocks are also forwarded from the transform and quantizationcomponent 313 to an inverse transform and quantization component 329 forreconstruction into reference blocks for use by the motion compensationcomponent 321. The inverse transform and quantization component 329 maybe substantially similar to the scaling and inverse transform component229. In-loop filters in an in-loop filters component 325 are alsoapplied to the residual blocks and/or reconstructed reference blocks,depending on the example. The in-loop filters component 325 may besubstantially similar to the filter control analysis component 227 andthe in-loop filters component 225. The in-loop filters component 325 mayinclude multiple filters as discussed with respect to in-loop filterscomponent 225. The filtered blocks are then stored in a decoded picturebuffer component 323 for use as reference blocks by the motioncompensation component 321. The decoded picture buffer component 323 maybe substantially similar to the decoded picture buffer component 223.

FIG. 4 is a block diagram illustrating an example video decoder 400.Video decoder 400 may be employed to implement the decoding functions ofcodec system 200 and/or implement steps 111, 113, 115, and/or 117 ofoperating method 100. Decoder 400 receives a bitstream, for example froman encoder 300, and generates a reconstructed output video signal basedon the bitstream for display to an end user.

The bitstream is received by an entropy decoding component 433. Theentropy decoding component 433 is configured to implement an entropydecoding scheme, such as CAVLC, CABAC, SBAC, PIPE coding, or otherentropy coding techniques. For example, the entropy decoding component433 may employ header information to provide a context to interpretadditional data encoded as codewords in the bitstream. The decodedinformation includes any desired information to decode the video signal,such as general control data, filter control data, partitioninformation, motion data, prediction data, and quantized transformcoefficients from residual blocks. The quantized transform coefficientsare forwarded to an inverse transform and quantization component 429 forreconstruction into residual blocks. The inverse transform andquantization component 429 may be similar to inverse transform andquantization component 329.

The reconstructed residual blocks and/or prediction blocks are forwardedto intra-picture prediction component 417 for reconstruction into imageblocks based on intra-prediction operations. The intra-pictureprediction component 417 may be similar to intra-picture estimationcomponent 215 and an intra-picture prediction component 217.Specifically, the intra-picture prediction component 417 employsprediction modes to locate a reference block in the frame and applies aresidual block to the result to reconstruct intra-predicted imageblocks. The reconstructed intra-predicted image blocks and/or theresidual blocks and corresponding inter-prediction data are forwarded toa decoded picture buffer component 423 via an in-loop filters component425, which may be substantially similar to decoded picture buffercomponent 223 and in-loop filters component 225, respectively. Thein-loop filters component 425 filters the reconstructed image blocks,residual blocks and/or prediction blocks, and such information is storedin the decoded picture buffer component 423. Reconstructed image blocksfrom decoded picture buffer component 423 are forwarded to a motioncompensation component 421 for inter-prediction. The motion compensationcomponent 421 may be substantially similar to motion estimationcomponent 221 and/or motion compensation component 219. Specifically,the motion compensation component 421 employs motion vectors from areference block to generate a prediction block and applies a residualblock to the result to reconstruct an image block. The resultingreconstructed blocks may also be forwarded via the in-loop filterscomponent 425 to the decoded picture buffer component 423. The decodedpicture buffer component 423 continues to store additional reconstructedimage blocks, which can be reconstructed into frames via the partitioninformation. Such frames may also be placed in a sequence. The sequenceis output toward a display as a reconstructed output video signal.

FIG. 5 is a schematic diagram illustrating an example bitstream 500containing an encoded video sequence. For example, the bitstream 500 canbe generated by a codec system 200 and/or an encoder 300 for decoding bya codec system 200 and/or a decoder 400. As another example, thebitstream 500 may be generated by an encoder at step 109 of method 100for use by a decoder at step 111.

The bitstream 500 includes a sequence parameter set (SPS) 510, aplurality of picture parameter sets (PPSs) 512, a plurality of sliceheaders 514, and image data 520. An SPS 510 contains sequence datacommon to all the pictures in the video sequence contained in thebitstream 500. Such data can include picture sizing, bit depth, codingtool parameters, bit rate restrictions, etc. The PPS 512 containsparameters that are specific to each picture. Hence, there may be onePPS 512 per picture in the video sequence. The PPS 512 can indicatecoding tools available for slices in corresponding pictures,quantization parameters, offsets, picture specific coding toolparameters (e.g., filter controls), etc. The slice header 514 containsparameters that are specific to each slice in a picture. Hence, theremay be one slice header 514 per slice in the video sequence. The sliceheader 514 may contain slice type information, picture order counts(POCs), reference picture lists, prediction weights, tile entry points,deblocking parameters, etc.

The image data 520 contains video data encoded according tointer-prediction and/or intra-prediction as well as correspondingtransformed and quantized residual data. Such image data 520 is sortedaccording to the partitioning used to partition the image prior toencoding. For example, the image in the image data 520 is divided intoslices 521. Each slice 521 is further divided into tiles 523. The tiles523 are further divided into CTUs 527. The CTUs 527 are further dividedinto coding blocks based on coding trees. The coding blocks can then beencoded/decoded according to prediction mechanisms. An image/picture cancontain one or more slices 521. One slice header 514 is employed perslice 521. Each slice 521 can contain one or more tiles 523, which canthen contain a plurality of CTUs 527.

Each slice 521 may be a rectangle defined by a tile 523 at an upper-leftcorner and a tile 523 at a bottom-right corner. Unlike in other codingsystems, a slice 521 may not traverse the entire width of a picture. Aslice 521 is the smallest unit that can be separately displayed by adecoder. Hence, splitting slices 521 into smaller units allows forsub-pictures to be generated in a manner that is granular enough todisplay desired areas of a picture. For example, in a virtual reality(VR) context, a picture may contain an entire viewable sphere of data,but a user may only view a sub-picture on a head mounted display.Smaller slices 521 allows for such sub-pictures to be separatelysignaled. A slice 521 is also generally signaled in a separate VCL NALunit 533. Also, a slice 521 may not allow prediction based on otherslices 521, which allows each slice 521 to be coded independently ofother slices 521.

The slices 521 are partitioned into an integer number of tiles 523. Atile 523 is a partitioned portion of a slice 521 created by horizontaland vertical boundaries. Tiles 523 may be coded in raster scan order,and may or may not allow prediction based on other tiles 523, dependingon the example. Each tile 523 may have a unique tile ID 524 in thepicture. A tile ID 524 is a numerical identifier that can be used todistinguish one tile 523 from another. A tile ID 524 may take the valueof a tile index that increases numerically in raster scan order. Rasterscan order is left to right and top to bottom. The tile IDs 524 may alsoemploy other numerical values. However, the tile ID 524 should alwaysincrease in raster scan order to support the computations discussedherein. For example, the boundaries of the slice 521 can be determinedaccording to the tile ID 524 of the tile 523 at the upper-left corner ofthe slice 521 and the tile ID 524 of the tile 523 at the bottom-rightcorner of the slice 521. When the tile ID 524 is a different value froma tile index, a conversion mechanism can be signaled in the bitstream500, for example in the PPS 512. Further, each tile 523 may beassociated with an entry point offset 525. The entry point offset 525indicates the location of the first bit of coded data associated withthe tile 523. The first tile 523 may have an entry point offset 525 ofzero and further tiles 523 may each have an entry point offset 525 equalto the number of bits of coded data in preceding tiles 523. As such, thenumber of entry point offsets 525 can be inferred to be one less thanthe number of tiles 523.

Tiles 523 are further divided into CTUs 527. A CTU 527 is a sub-portionof a tile 523 that can be further subdivided by a coding tree structureinto coding blocks that can be encoded by an encoder and decoded by adecoder. The CTUs 527 are each associated with a CTU address 529. A CTUaddress 529 denotes the location of a corresponding CTU 527 in thebitstream 500. Specifically, a CTU address 529 may denote the locationof a corresponding CTU 527 in a VCL NAL unit 533. In some examples, theCTU addresses 529 for the CTUs 527 may be explicitly signaled, forexample in the PPS 512. In other examples, CTU addresses 529 can bederived by the decoder. For example, the CTU addresses 529 can beassigned based on the tile ID 524 of the tile 523 that contains thecorresponding CTUs 527. In such a case, the decoder can determine thetiles 523 in a slice 521 based on the tile IDs 524 of the upper-left andbottom-right tiles 523. The decoder can then use the determined tiles523 in the slice 521 to determine the number of CTUs 527 in the slice521. Further, the decoder can use the known tile IDs 524 and the numberof CTUs 527 to determine the CTU addresses 529. In addition, as thedecoder is aware of the number of CTUs 527, a flag that indicateswhether each CTU 527 is the last CTU 527 in a VCL NAL unit 533 can beomitted. This is because the decoder can determine which CTU 527 is thelast CTU 527 in a VCL NAL unit 533 by being aware of the number of CTUs527 in the slice 521, which is contained in the VCL NAL unit 533.However, a padding bit may be placed after the last CTU 527 in a tile523 in order to assist in distinguishing between tiles 523 in someexamples. As can be seen, signaling slice 521 boundaries based on tileIDs 524 can allow the decoder to infer a significant amount of data,which can then be omitted from the bitstream 500 in order to increasecoding efficiency.

The bitstream 500 is positioned into VCL NAL units 533 and Non-VCL NALunits 531. A NAL unit is a coded data unit sized to be placed as apayload for a single packet for transmission over a network. A VCL NALunit 533 is a NAL unit that contains coded video data. For example, eachVCL NAL unit 533 may contain one slice 521 of data includingcorresponding tiles 523, CTUs 527, and coding blocks. A Non-VCL NAL unit531 is a NAL unit that contains supporting syntax, but does not containcoded video data. For example, a Non-VCL NAL unit 531 may contain theSPS 510, a PPS 512, a slice header 514, etc. As such, the decoderreceives the bitstream 500 in discrete VCL NAL units 533 and Non-VCL NALunits 531. In streaming applications, the decoder may decode presentvideo data without waiting for the entire bitstream 500 to be received.As such, tile IDs 524, entry point offsets 525, and CTU addresses 529allow the decoder to correctly locate the video data in the VCL NAL unit533 for fast decoding, parallel processing, and other video displaymechanisms. Accordingly, computing tile IDs 524, entry point offsets525, and/or CTU addresses 529 allows for the implementation of efficientdecoding and display mechanisms while reducing the size of the bitstream500 and hence increasing coding efficiency.

FIG. 6 is a schematic diagram illustrating an example image 600partitioned for coding. For example, an image 600 can be encoded in anddecoded from a bitstream 500, for example by a codec system 200, anencoder 300, and/or a decoder 400. Further, the image 600 can bepartitioned to support encoding and decoding according to method 100.

The image 600 can be partitioned into slices 621, tiles 623, and CTUs627, which may be substantially similar to slices 521, tiles 523, andCTUs 527, respectively. In FIG. 6, the slices 621 are depicted by boldlines with alternative white backgrounds and hashing to graphicallydifferentiate between slices 621. The tiles 623 are shown by dashedlines. Tile 623 boundaries positioned on slice 621 boundaries aredepicted as dashed bold lines and tile 623 boundaries that are notpositioned on slice 621 boundaries are depicted as non-bold dashedlines. The CTU 627 boundaries are depicted as solid non-bold linesexcept for locations where the CTU 627 boundaries are covered by tile623 or slice 621 boundaries. In this example, image 600 includes nineslices 621, twenty four tiles 623, and two hundred sixteen CTUs 627.

As shown, a slice 621 is a rectangle with boundaries that may be definedby the included tiles 623. The slice 621 may not extend across theentire width of the image 600. Tiles 623 can be generated in the slices621 according to rows and columns. CTUs 627 can then be partitioned fromthe tiles 623 to create image 600 partitions suitable to be subdividedinto coding blocks for coding according to inter-prediction and/orintra-prediction.

By employing the forgoing, video coding systems can be improved. Forexample, slices are designed such that CTUs contained in a slice may notbe simply a set of CTUs of a picture following a CTU raster scan orderof the picture. But rather a slice is defined as a set of CTUs thatcover a rectangular region of a picture. Further, each slice is in itsown NAL unit. Also, the addresses of the CTUs contained in a slice canbe signaled by signaling, in the slice header, the CTU addresses inraster scan order of the top-left and bottom-right CTUs in the slice.Further, slices are designed to contain and only contain a set ofcomplete tiles covering a rectangular region of a picture. Each slice isin its own NAL unit. This way, the purpose of having more than one slicemay be to put a set of tiles covering a rectangular region of a pictureinto a NAL unit. In some cases, there are one or more slices in apicture, and each of these slices can contain a set of complete tilescovering a rectangular region. There may also be one other slice in thepicture covering the rest of the tiles of the picture. The regioncovered by this slice may be a rectangular region with a hole that iscovered by other slices. For example, for region of interest purposes, apicture may contain two slices in which one slice contains a set ofcomplete tiles covering the region of interest and the other slicecontains the remaining tiles of the picture.

The addresses of the CTUs contained in a slice may be explicitly orimplicitly signaled by the tile IDs of the tiles contained in the slice.For efficient signaling, only the tile IDs of the top-left and thebottom-right tiles may be signaled in some examples. For furtherimproved signaling efficiency, a flag indicating whether the slicecontains a single tile can signaled, and if yes, only one tile ID may besignaled. In other cases, all tile IDs contained in a slice aresignaled. In some examples, tile ID values are assigned to be the sameas the tile index within the picture. The length, in bits, forexplicitly signaling tile IDs in a slice header for derivation of theaddresses of the CTUs contained in a slice, can be derived according tothe number of tiles in the picture (e.g., cell of log two of number oftiles in a picture). The number of tiles in the picture can be eitherexplicitly signaled in a parameter set or derived per the tileconfiguration signaled in a parameter set. In some examples, the length,in bits, for explicitly signaling tile IDs in a slice header forderivation of the addresses of the CTUs contained in a slice can besignaled in a parameter set. In some examples, the number of entrypoints, which is equal to the number of tiles in the slice minus 1, isderived and is not signaled in the slice header. In another example,signaling of a flag for each CTU indicating whether the CTU is the endof a slice is avoided.

In some examples, slices and tiles are designed such that rewriting ofthe slice headers is not needed when extracting a set of tiles, such asmotion constrained tile sets (MCTSs), from a bitstream to create aconforming sub-bitstream. For example, the tile ID may be explicitlysignaled for each tile in the parameter set in which the tileconfiguration is signaled. The tile IDs are each unique within apicture. Tile IDs may not be continuous within a picture. However, tileIDs should be organized in increasing order (e.g., monotonouslyincreasing) in the direction of the tile raster scan of a picture. Withthis, the decoding order of slices in a picture can be restricted to bein increasing value of the tile ID of the top-left tile. When the tileID is not explicitly signaled and inferred to be the same as tile index,the following can be used for signaling tile ID values in slice headers.A flag indicating whether the slice is the first slice of the picturecan be signaled. When the flag indicating that the slice is the firstslice of the picture, the signaling of the tile ID of the top-left tileof the slice can be omitted as it can be inferred to be the tile withlowest tile index (e.g., tile index zero—assuming tile index starts fromzero).

In another example, a picture may contain zero, or one or more MCTSs. AnMCTS may contain one or more tiles. When a tile in a slice is part of anMCTS, the MCTS is constrained so that all tiles in the slice are part ofthe same MCTS. The slice may be further constrained so that the tileconfiguration for all pictures containing tiles of an MCTS is the sameregarding the positions and sizes of the tiles within the MCTS. In someexamples, the slice is constrained such that an MCTS is exclusivelycontained in a slice. This has two consequences. In this case, each MCTSis in a separate NAL unit. Further, each MCTS is in rectangular shape.

The signaling of MCTSs may be as follows. A flag can be signaled in aslice header to indicate whether the slice contains NAL units with anMCTS in the access unit containing the corresponding slice. Othersupporting information for MCTS (e.g., profile, tier and levelinformation of sub-bitstream resulting from extracting the MCTS) issignaled in an SEI message. Alternatively, both the flag indication andsupporting information of MCTS can be signaled in an SEI message. Toenable signaling of treatment of MCTS boundaries as picture boundaries asyntax element indicating whether all tile boundaries are treated thesame as picture boundaries is signaled, for example in the parameter setwherein tile configuration is signaled. In addition, a syntax elementindicating whether all slice boundaries of a slice are treated the sameas picture boundaries may be signaled in the slice header, for examplewhen other syntax elements do not indicate that all tile boundaries aretreated the same as picture boundaries.

A syntax element indicating whether the in-loop filtering operations maybe applied across each tile boundary may be signaled only when syntaxdoes not otherwise indicate that all tile boundaries are treated thesame as picture boundaries. In this case, treating a tile boundary aspicture boundary indicates that, among other aspects, no in-loopfiltering operations may be applied across each tile boundary. In otherexamples, a syntax element indicating whether the in-loop filteringoperations may be applied across each tile boundary is signaledindependently of indications of whether all tile boundaries are treatedthe same as picture boundaries. In this case, treating a tile boundaryas picture boundary indicates that in-loop filtering operations maystill be applied across each tile boundary.

In some examples, an MCTS boundary is treated as a picture boundary.Further, the syntax element in the slice header that indicates whetherthe slice boundary is treated the same as the picture boundary can alsobe made conditional to the flag that indicates whether the slicecontains MCTS. In some cases, the value of a flag indicating that theMCTS boundary is to be treated as a picture boundary can be inferredwhen the flag in the slice header indicates the slice contains MCTS.

When the boundaries of a tile or slice are indicated to be treated aspicture boundaries, the following applies. In the derivation process fortemporal luma motion vector prediction, the right and bottom pictureboundary positions used in the process, indicated bypic_height_in_luma_samples−1 and pic_width_in_luma_samples−1,respectively, are replaced with the right and the bottom boundarypositions, respectively, of the tile or slice, in units of luma samples.In the luma sample interpolation process, the left, right, top, andbottom picture boundary positions used in the process, indicated by 0,pic_height_in_luma_samples−1, 0, pic_width_in_luma_samples−1,respectively, are replaced with the left, right, top, and bottomboundary positions, respectively, of the tile or slice, in units of lumasamples, respectively. In the chroma sample interpolation process, theleft, right, top, and bottom picture boundary positions used in theprocess, indicated by 0, pic_height_in_luma_samples/SubWidthC−1, 0,pic_width_in_luma_samples/SubWidthC−1, respectively, are replaced withthe left, right, top, and bottom boundary positions, respectively, ofthe tile or slice, in units of chroma samples, respectively.

The preceding mechanisms can be implemented as follows. A slice isdefined as an integer number of tiles that cover a rectangular region ofa picture and that are exclusively contained in a single NAL unit. Aslice header is defined as a part of a coded slice containing the dataelements pertaining to all tiles represented in the slice. A tile isdefined as a rectangular region of CTUs within a particular tile columnand a particular tile row in a picture. A tile column is defined as arectangular region of CTUs having a height equal to the height of thepicture and a width specified by syntax elements in the pictureparameter set. A tile row is defined as a rectangular region of CTUshaving a height specified by syntax elements in the picture parameterset and a width equal to the width of the picture. A tile scan isdefined as a specific sequential ordering of CTUs partitioning a picturein which the CTUs are ordered consecutively in CTU raster scan in a tilewhereas tiles in a picture are ordered consecutively in a raster scan ofthe tiles of the picture.

This section specifies how a picture is partitioned into slices andtiles. Pictures are divided into slices and tiles. A slice is a sequenceof tiles that cover a rectangular region of a picture. A tile is asequence of CTUs that cover a rectangular region of a picture.

When a picture is coded using three separate color planes(separate_colour_plane_flag is equal to 1), a slice contains only CTUsof one color component being identified by the corresponding value ofcolour_plane_id, and each color component array of a picture includesslices having the same colour_plane_id value. Coded slices withdifferent values of colour_plane_id within a picture may be interleavedwith each other under the constraint that for each value ofcolour_plane_id, the coded slice NAL units with that value ofcolour_plane_id shall be in the order of increasing CTU address in tilescan order for the first CTU of each coded slice NAL unit. It should benoted that when separate_colour_plane_flag is equal to 0, each CTU of apicture is contained in exactly one slice. Whenseparate_colour_plane_flag is equal to 1, each CTU of a color componentis contained in exactly one slice (e.g., information for each CTU of apicture is present in exactly three slices and these three slices havedifferent values of colour_plane_id).

The following divisions of processing elements of this specificationform spatial or component-wise partitioning: the division of eachpicture into components; the division of each component into CTBs; thedivision of each picture into tile columns; the division of each pictureinto tile rows; the division of each tile column into tiles; thedivision of each tile row into tiles; the division of each tile intoCTUs; the division of each picture into slices; the division of eachslice into tiles; the division of each slice into CTUs; the division ofeach CTU into CTBs; the division of each CTB into coding blocks, exceptthat the CTBs are incomplete at the right component boundary when thecomponent width is not an integer multiple of the CTB size and the CTBsare incomplete at the bottom component boundary when the componentheight is not an integer multiple of the CTB size; the division of eachCTU into coding units, except that the CTUs are incomplete at the rightpicture boundary when the picture width in luma samples is not aninteger multiple of the luma CTB size and the CTUs are incomplete at thebottom picture boundary when the picture height in luma samples is notan integer multiple of the luma CTB size; the division of each codingunit into transform units; the division of each coding unit into codingblocks; the division of each coding block into transform blocks; and thedivision of each transform unit into transform blocks.

Inputs into the derivation process for neighboring block availabilityare the luma location (xCurr, yCurr) of the top-left sample of thecurrent block relative to the top-left luma sample of the currentpicture, and the luma location (xNbY, yNbY) covered by a neighboringblock relative to the top-left luma sample of the current picture. Theoutputs of this process are the availability of the neighboring blockcovering the location (xNbY, yNbY), denoted as availableN. Theneighboring block availability availableN is derived as follows. If oneor more of the following conditions are true, availableN is set equal tofalse. The top_left_tile_id of the slice containing the neighboringblock differs in value from the top_left_tile_id of the slice containingthe current block or the neighboring block is contained in a differenttile than the current block.

The CTB raster and tile scanning process is as follows. The listColWidth[i] for i ranging from 0 to num_tile_columns_minus1, inclusive,specifying the width of the i-th tile column in units of CTBs, isderived as follows.

if( uniform_tile_spacing_flag )  for( i = 0; i <=num_tile_columns_minus1; i++ )   ColWidth[ i ] = ( ( i + 1 ) *PicWidthInCtbsY ) / ( num_tile_columns_minus1 + 1) − ( i *PicWidthInCtbsY ) / ( num_tile_columns_minus1 + 1 ) else { ColWidth[num_tile_columns_minus1 ] = PicWidthInCtbsY    (6-1)  for( i = 0; i <num_tile_columns_minus1; i++) {   ColWidth[ i ] =tile_column_width_minus1[ i ] + 1   ColWidth[ num_tile_columns_minus1 ]−= ColWidth[ i ]  } }

The list RowHeight[j] for j ranging from 0 to num_tile_rows_minus1,inclusive, specifying the height of the j-th tile row in units of CTBs,is derived as follows.

if( uniform_tile_spacing_flag )  for( j = 0; j <= num_tile_rows_minus1;j++ )   RowHeight[ j ] = ( ( j + 1 ) * PicHeightInCtbsY ) /   (num_tile_rows_minus1 + 1 ) − ( j * PicHeightInCtbsY ) / (num_tile_rows_minus1 + 1 ) else {  RowHeight[ num_tile_rows_minus1 ] =PicHeightInCtbsY    (6-2)  for( j = 0; j < num_tile_rows_minus1; j++ ) {  RowHeight[ j ] = tile_row_height_minus1[ j ] + 1   RowHeight[num_tile_rows_minus1 ] −= RowHeight[ j ]  } }

The list ColBd[i] for i ranging from 0 to num_tile_columns_minus1+1,inclusive, specifying the location of the i-th tile column boundary inunits of CTBs, is derived as follows: for(ColBd[0]=0, i=0;i<=num_tile_columns_minus1; i++)

ColBd[i+1]=ColBd[i]+ColWidth[i]  (6-3)

The list RowBd[j] for j ranging from 0 to num_tile_rows_minus1+1,inclusive, specifying the location of the j-th tile row boundary inunits of CTBs, is derived as follows: for(RowBd[0]=0, j=0;j<=num_tile_rows_minus1; j++)

RowBd[j+1]=RowBd[j]+RowHeight[j]  (6-4)

The list CtbAddrRsToTs[ctbAddrRs] for ctbAddrRs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in CTB raster scan of a picture to a CTB address in tile scan,is derived as follows:

for( ctbAddrRs = 0; ctbAddrRs < PicSizeInCtbsY; ctbAddrRs++ ) {  tbX =ctbAddrRs % PicWidthInCtbsY  tbY = ctbAddrRs / PicWidthInCtbsY  for( i =0; i <= num_tile_columns_minus1; i++ )   if( tbX >= ColBd[ i ] )   tileX = i  for( j = 0; j <= num_tile_rows_minus1; j++ )         (6-5)   if( tbY >= RowBd[ j ] )    tileY = j  CtbAddrRsToTs[ctbAddrRs ] = 0  for( i = 0; i < tileX; i++ )   CtbAddrRsToTs[ ctbAddrRs] += RowHeight[ tileY ] * ColWidth[ i ]  for( j = 0; j < tileY; j++ )  CtbAddrRsToTs[ ctbAddrRs ] += PicWidthInCtbsY * RowHeight[ j ] CtbAddrRsToTs[ ctbAddrRs ] += ( tbY − RowBd[ tileY ] ) * ColWidth[tileX ] + tbX − ColBd[ tileX ] }

The list CtbAddrTsToRs[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a CTB address in CTB raster scan of a picture,is derived as follows:

for(ctbAddrRs=0;ctbAddrRs<PicSizeInCtbsY;ctbAddrRs++)  (6-6)

CtbAddrTsToRs[CtbAddrRsToTs[ctbAddrRs]]=ctbAddrRs

The list TileId[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a tile ID, is derived as follows:

for( j = 0, tileIdx = 0; j <= num_tile_rows_minus1; j++ )  for( i = 0; i<= num_tile_columns_minus1; i++, tileIdx++ )   for( y = RowBd[ j ]; y <RowBd[ j + 1 ]; y++ )       (6-7)    for( x = ColBd[ i ]; x < ColBd[ i +1 ]; x++ )     TileId[ CtbAddrRsToTs[ y * PicWidthInCtbsY + x ] ] =     explicit_tile_id_flag ? tile_id_val[ i ][ j ] : tileIdxThe list NumCtusInTile[tileIdx] for tileIdx ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a tile indexto the number of CTUs in the tile, is derived as follows:

for( j = 0, tileIdx = 0; j <= num_tile_rows_minus1; j++ )  for( i = 0; i<= num_tile_columns_minus1; i++, tileIdx++ )    (6-8)   NumCtusInTile[tileIdx ] = ColWidth[ i ] * RowHeight[ j ]

The set TileIdToIdx[tileId] for a set of NumTilesInPic tileId valuesspecifying the conversion from a tile ID to a tile index and the listFirstCtbAddrTs[tileIdx] for tileIdx ranging from 0 to NumTilesInPic−1,inclusive, specifying the conversion from a tile ID to the CTB addressin tile scan of the first CTB in the tile are derived as follows:

  for( ctbAddrTs = 0, tileIdx = 0, tileStartFlag = 1; ctbAddrTs <PicSizeInCtbsY; ctbAddrTs++ ) {  if( tileStartFlag ) {   TileIdToIdx[TileId[ ctbAddrTs ] ] = tileIdx   FirstCtbAddrTs[ tileIdx ] = ctbAddrTs        (6-9)   tileStartFlag = 0  }  tileEndFlag = ctbAddrTs = =PicSizeInCtbsY − 1 | | TileId[ ctbAddrTs + 1 ] != TileId[ ctbAddrTs ] if( tileEndFlag ) {   tileIdx++   tileStartFlag = 1  } }

The values of ColumnWidthInLumaSamples[i], specifying the width of thei-th tile column in units of luma samples, are set equal toColWidth[i]<<Ctb Log 2SizeY for i ranging from 0 tonum_tile_columns_minus1, inclusive. The values ofRowHeightInLumaSamples[j], specifying the height of the j-th tile row inunits of luma samples, are set equal to RowHeight[j]<<Ctb Log 2SizeY forj ranging from 0 to num_tile_rows_minus1, inclusive.

The picture parameter set RBSP syntax is as follows:

TABLE 1 Descriptor pic_parameter_set_rbsp( ) {  pps_pic_parameter_set_idue(v)  pps_seq_parameter_set_id ue(v)  transform_skip_enabled_flag u(1) single_tile_in_pic_flag u(1)  if( !single_tile_in_pic_flag ) {  num_tile_columns_minus1 ue(v)   num_tile_rows_minus1 ue(v)  } tile_id_len_minus1 ue(v)  explicit_tile_id_flag u(1)  if(explicit_tile_id_flag )   for( i = 0; i <= num_tile_columns_minus1; i++)    for( j = 0; j <= num_tile_rows_minus1; j++ )     tile_id_val[ i ][j ] u(v)  if( !single_tile_in_pic_flag ) {   uniform_tile_spacing_flagu(1)   if( !uniform_tile_spacing_flag ) {    for( i = 0; i <num_tile_columns_minus1; i++ )     tile_column_width_minus1[ i ] ue(v)   for( i = 0; i < num_tile_rows_minus1; i++ )    tile_row_height_minus1[ i ] ue(v)   }  tile_boundary_treated_as_pic_boundary_flag u(1)   if(!tile_boundary_treated_as_pic_boundary_flag )   loop_filter_across_tiles_enabled_flag u(1)  }  rbsp_trailing_bits( )}

The slice header syntax is changed as follows.

TABLE 2 Descriptor slice_header( ) {  slice_pic_parameter_set_id ue(v) single_tile_in_slice_flag // Same note as below u(1)  top_left_tile_id// Note that this is needed even when there is only one u(v) tile in thepicture to enable extraction of a single motion-constrained tile to be aconforming bitstream without the need of changing the slice header.  if(!single_tile_in_slice_flag )   bottom_right_tile_id u(v)  slice_typeue(v)  if ( slice_type != I )   log2_diff_ctu_max_bt_size ue(v) dep_quant_enabled_flag u(1)  if( !dep_quant_enabled_flag )  sign_data_hiding_enabled_flag u(1)  if(!tile_boundary_treated_as_pic_boundary_flag )  slice_boundary_treated_as_pic_boundary_flag  if(!single_tile_in_slice_flag ) {   offset_len_minus1 ue(v)   for( i = 0; i< NumTilesInSlice − 1; i++ )    entry_point_offset_minus1[ i ] u(v)  } byte_alignment( ) }

The slice_data( ) syntax is as follows:

TABLE 3 Descriptor slice_data( ) {  tileIdx = TileIdToIdx[top_left_tile_id ]  for( j = 0; j < NumTileRowsInSlice; j++, tileIdx +=num_tile_columns_minus1 + 1 ) {   for( i = 0, CurrTileIdx = tileIdx; i <NumTileColumnsInSlice; i++, CurrTileIdx++ ) {    ctbAddrInTs =FirstCtbAddrTs[ CurrTileIdx ]    for( k = 0; k < NumCtusInTile[CurrTileIdx ]; k++, ctbAddrInTs++ ) {     CtbAddrInRs = CtbAddrTsToRs[ctbAddrInTs ]     coding_tree_unit( )    }    end_of_tile_one_bit /*equal to 1 */ ae(v)    if( i < NumTileRowsInSlice − 1 | | j <NumTileColunmsInSlice − 1 )     byte_alignment( )   }  } }

The Picture parameter set RBSP semantics are as follows. Thesingle_tile_in_pic_flag is set equal to one to specify that there isonly one tile in each picture referring to the PPS. Thesingle_tile_in_pic_flag is set equal to zero to specify that there ismore than one tile in each picture referring to the PPS. Bitstreamconformance may require that the value of single_tile_in_pic_flag shallbe the same for all PPSs that are activated within a coded videosequence (CVS). The num_tile_columns_minus1 plus 1 specifies the numberof tile columns partitioning the picture. The num_tile_columns_minus1shall be in the range of zero to PicWidthInCtbsY−1, inclusive. When notpresent, the value of num_tile_columns_minus1 is inferred to be equal tozero. The num_tile_rows_minus1 plus 1 specifies the number of tile rowspartitioning the picture. The num_tile_rows_minus1 shall be in the rangeof zero to PicHeightInCtbsY−1, inclusive. When not present, the value ofnum_tile_rows_minus1 is inferred to be equal to zero. The variableNumTilesInPic is set equal to(num_tile_columns_minus1+1)*(num_tile_rows_minus1+1).

When single_tile_in_pic_flag is equal to zero, NumTilesInPic shall begreater than zero. The tile_id_len_minus1 plus 1 specifies the number ofbits used to represent the syntax element tile_id_val[i][j], whenpresent, in the PPS and the syntax elements top_left_tile_id andbottom_right_tile_id, when present, in slice headers referring to thePPS. The value of tile_id_len_minus1 shall be in the range of Ceil(Log2(NumTilesInPic) to 15, inclusive. The explicit_tile_id_flag is setequal to one to specify that the tile ID for each tile is explicitlysignaled. The explicit_tile_id_flag is set equal to zero to specify thattile IDs are not explicitly signaled. The tile_id_val[i][j] specifiesthe tile ID of the tile of the i-th tile column and the j-th tile row.The length of tile_id_val[i][j] is tile_id_len_minus1+1 bits.

For any integer m in the range of zero to num_tile_columns_minus1,inclusive, and any integer n in the range of zero tonum_tile_rows_minus1, inclusive, tile_id_val[i][j] shall not be equal totile_id_val[m][n] when i is not equal to m or j is not equal to n, andtile_id_val[i][j] shall be less than tile_id_val[m][n] whenj*(num_tile_columns_minus1+1)+i is less thann*(num_tile_columns_minus1+1)+m. The uniform_tile_spacing_flag is setequal to one to specify that tile column boundaries and likewise tilerow boundaries are distributed uniformly across the picture. Theuniform_tile_spacing_flag is set equal to zero to specify that tilecolumn boundaries and likewise tile row boundaries are not distributeduniformly across the picture but signaled explicitly using the syntaxelements tile_column_width_minus1[i] and tile_row_height_minus1[i]. Whennot present, the value of uniform_tile_spacing_flag is inferred to beequal to 1. The tile_column_width_minus1[i] plus 1 specifies the widthof the i-th tile column in units of CTBs. The tile_row_height_minus1[i]plus 1 specifies the height of the i-th tile row in units of CTBs.

The following variables are derived by invoking the CTB raster and tilescanning conversion process: the list ColWidth[i] for i ranging from 0to num_tile_columns_minus1, inclusive, specifying the width of the i-thtile column in units of CTBs; the list RowHeight[j] for j ranging from 0to num_tile_rows_minus1, inclusive, specifying the height of the j-thtile row in units of CTBs; the list ColBd[i] for i ranging from 0 tonum_tile_columns_minus1+1, inclusive, specifying the location of thei-th tile column boundary in units of CTBs; the list RowBd[j] for jranging from 0 to num_tile_rows_minus1+1, inclusive, specifying thelocation of the j-th tile row boundary in units of CTBs; the listCtbAddrRsToTs[ctbAddrRs] for ctbAddrRs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in the CTB raster scan of a picture to a CTB address in the tilescan; the list CtbAddrTsToRs[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in the tile scan to a CTB address in the CTB raster scan of apicture; the list TileId[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a tile ID; the list NumCtusInTile[tileIdx] fortileIdx ranging from 0 to PicSizeInCtbsY−1, inclusive, specifying theconversion from a tile index to the number of CTUs in the tile; the setTileIdToIdx[tileId] for a set of NumTilesInPic tileId values specifyingthe conversion from a tile ID to a tile index and the listFirstCtbAddrTs[tileIdx] for tileIdx ranging from 0 to NumTilesInPic−1,inclusive, specifying the conversion from a tile ID to the CTB addressin tile scan of the first CTB in the tile; the listsColumnWidthInLumaSamples[i] for i ranging from 0 tonum_tile_columns_minus1, inclusive, specifying the width of the i-thtile column in units of luma samples; and the listRowHeightInLumaSamples[j] for j ranging from 0 to num_tile_rows_minus1,inclusive, specifying the height of the j-th tile row in units of lumasamples.

The values of ColumnWidthInLumaSamples[i] for i ranging from 0 tonum_tile_columns_minus1, inclusive, and RowHeightInLumaSamples[j] for jranging from 0 to num_tile_rows_minus1, inclusive, shall all be greaterthan 0. The tile_boundary_treated_as_picture_boundary_flag is set equalto one to specify that each tile boundary is treated the same as thepicture boundary in the decoding process for pictures referring to thePPS. The tile_boundary_treated_as_picture_boundary_flag is set equal tozero to specify that each tile boundary may or may not be treated thesame as the picture boundary in the decoding process for picturesreferring to the PPS. When not present, the value oftile_boundary_treated_as_picture_boundary_flag is inferred to be equalto one. The loop_filter_across_tiles_enabled_flag is set equal to one tospecify that in-loop filtering operations may be performed across tileboundaries in pictures referring to the PPS. Theloop_filter_across_tiles_enabled_flag is set equal to zero to specifythat in-loop filtering operations are not performed across tileboundaries in pictures referring to the PPS. The in-loop filteringoperations include the deblocking filter, sample adaptive offset filter,and adaptive loop filter operations. When not present, the value ofloop_filter_across_tiles_enabled_flag is inferred to be equal to zero.

The slice header semantics are as follows. When present, the value ofthe slice header syntax element slice_pic_parameter_set_id shall be thesame in all slice headers of a coded picture. Theslice_pic_parameterset_id specifies the value ofpps_pic_parameter_set_id for the PPS in use. The value ofslice_pic_parameterset_id shall be in the range of 0 to 63, inclusive.The single_tile_in_slice_flag is set equal to one to specify that thereis only one tile in the slice. The single_picture_in_pic_flag is setequal to zero to specify that there is more than one tile in the slice.The top_left_tile_id specifies the tile ID of the tile located at thetop-left corner of the slice. The length of top_left_tile_id istile_id_len_minus1+1 bits. The value of top_left_tile_id shall not beequal to the value of top_left_tile_id of any other coded slice NAL unitof the same coded picture. When there is more than one slice in apicture, the decoding order of the slices in the picture shall be inincreasing value of top_left_tile_id. The bottom_right_tile_id specifiesthe tile ID of the tile located at the bottom-right corner of the slice.The length of bottom_right_tile_id is tile_id_len_minus1+1 bits. Whennot present, the value of bottom_right_tile_id is inferred to be equalto top_left_tile_id.

The variables NumTileRowsInSlice, NumTileColumnsInSlice, andNumTilesInSlice are derived as follows:

deltaTileIdx=TileIdToIdx[bottom_right_tile_id]−TileIdToIdx[top_left_tile_id]

NumTileRowsInSlice=(deltaTileIdx/(num_tile_columns_minus1+1))+1  (7-25)

NumTileColumnsInSlice=(deltaTileIdx % (num_tile_columns_minus1+1))+1

NumTilesInSlice=NumTileRowsInSlice*NumTileColumnsInSlice

The slice type specifies the coding type of the slice according to table4.

TABLE 4 slice_type Name of slice_type 0 B (B slice) 1 P (P slice) 2 I (Islice)When nal_unit_type has a value in the range of TBD, inclusive, e.g., thepicture is an Intra Random Access Picture (TRAP) picture, slice_typeshall be equal to two. The log 2_diff_ctu_max_bt_size specifies thedifference between the luma CTB size and the maximum luma size (width orheight) of a coding block that can be split using a binary split. Thevalue of log 2_diff_ctu_max_bt_size shall be in the range of zero to CtbLog 2SizeY−MinCbLog 2SizeY, inclusive. When log 2_diff_ctu_max_bt_sizeis not present, the value of log 2_diff_ctu_max_bt_size is inferred tobe equal to two.

The variables MinQtLog 2SizeY, MaxBtLog 2SizeY, MinBtLog 2SizeY,MaxTtLog 2SizeY, MinTtLog 2SizeY, MaxBtSizeY, MinBtSizeY, MaxTtSizeY,MinTtSizeY and MaxMttDepth are derived as follows:

MinQtLog 2SizeY=(slice_type==I)?MinQtLog 2SizeIntraY: MinQtLog2SizeInterY   (7-26)

MaxBtLog 2SizeY=Ctb Log 2SizeY−log 2_diff_ctu_max_bt_size  (7-27)

MinBtLog 2SizeY=MinCbLog 2SizeY  (7-28)

MaxTtLog 2SizeY=(slice_type==I)?5:6  (7-29)

MinTtLog 2SizeY=MinCbLog 2SizeY  (7-30)

MinQtSizeY=1<<MinQtLog 2SizeY  (7-31)

MaxBtSizeY=1<<MaxBtLog 2SizeY  (7-32)

MinBtSizeY=1<<MinBtLog 2SizeY  (7-33)

MaxTtSizeY=1<<MaxTtLog 2SizeY  (7-34)

MinTtSizeY=1<<MinTtLog 2SizeY  (7-35)

MaxMttDepth=(slice_type==I)?max_mtt_hierarchy_depth_intra_slices:max_mtt_hierarchy_depth_inter_slices  (7-36)

The dep_quant_enabled_flag is set equal to zero to specify thatdependent quantization is disabled. The dep_quant_enabled_flag is setequal to one to specify that dependent quantization is enabled. Thesign_data_hiding_enabled_flag is set equal to zero to specify that signbit hiding is disabled. The sign_data_hiding_enabled_flag is set equalto one to specify that sign bit hiding is enabled. Whensign_data_hiding_enabled_flag is not present, it is inferred to be equalto zero. The slice_boundary_treated_as_pic_boundary_flag is set equal toone to specify that each slice boundary of the slice is treated the sameas picture boundary in the decoding process. Theslice_boundary_treated_as_pic_boundary_flag equal to zero specifies thateach tile boundary may or may not be treated the same as pictureboundary in the decoding process. When not present, the value ofslice_boundary_treated_as_pic_boundary_flag is inferred to be equal toone. The offset_len_minus1 plus 1 specifies the length, in bits, of theentry_point_offset_minus1[i] syntax elements. The value ofoffset_len_minus1 shall be in the range of 0 to 31, inclusive. Theentry_point_offset_minus1[i] plus 1 specifies the i-th entry pointoffset in bytes, and is represented by offset_len_minus1 plus 1 bits.The slice data that follow the slice header consists of NumTilesInSlicesubsets, with subset index values ranging from 0 to NumTilesInSlice−1,inclusive. The first byte of the slice data is considered byte zero.When present, emulation prevention bytes that appear in the slice dataportion of the coded slice NAL unit are counted as part of the slicedata for purposes of subset identification.

Subset zero include bytes zero to entry_point_offset_minus1[0],inclusive, of the coded slice segment data, subset k, with k in therange of 1 to NumTilesInSlice−2, inclusive, includes bytes firstByte[k]to lastByte[k], inclusive, of the coded slice data with firstByte[k] andlastByte[k] defined as:

$\begin{matrix}{{{first}\; {{Byte}\lbrack\ k\rbrack}} = {\sum\limits_{n = 1}^{k}\left( {{{entry}_{-}{{point}\_ {offset}}_{-}{minus}\; {1\left\lbrack {n - 1} \right\rbrack}} + 1} \right.}} & \left( {7 - 37} \right) \\{{{last}\; {{Byte}\lbrack k\rbrack}} = {{{first}\; {{Byte}\lbrack k\rbrack}} + {entry_{-}point_{-}offset_{-}{minus}\; {1\lbrack k\rbrack}}}} & \left( {7 - 38} \right)\end{matrix}$

The last subset (with subset index equal to NumTilesInSlice−1) includesthe remaining bytes of the coded slice data. Each subset shall includeall coded bits of all CTUs in the slice that are within the same tile.

The general slice data semantics are as follows: The end_of_tile_one_bitshall be equal to one. For each tile, the variables LeftBoundaryPos,TopBoundaryPos, RightBoundaryPos and BotBoundaryPos are derived asfollows. If tile_boundary_treated_as_pic_boundary_flag is equal to true,the following applies:

tileColIdx=CurrTileIdx/(num_tile_columns_minus1+1)  (7-39)

tileRowIdx=CurrTileIdx % (num_tile_columns_minus1+1)  (7-40)

LeftBoundaryPos=ColBd[tileColIdx]<<Ctb Log 2SizeY  (7-41)

RightBoundaryPos=((ColBd[tileColIdx]+ColWidth[tileColIdx])<<Ctb Log2SizeY)−1  (7-42)

TopBoundaryPos=RowBd[tileRowIdx]<<Ctb Log 2SizeY  (7-43)

BotBoundaryPos=((RowBd[tileRowIdx]+RowHeight[tileRowIdx])<<Ctb Log2SizeY)−1  (7-44)

Otherwise if slice_boundary_treated_as_pic_boundary_flag is equal totrue, the following applies:

sliceFirstTileColIdx=TileIdToIdx[top_left_tile_id]/(num_tile_columns_minus1+1)  (7-45)

sliceFirstTileRowIdx=TileIdToIdx[top_left_tile_id]%(num_tile_columns_minus1+1)   (7-46)

sliceLastTileColIdx=TileIdToIdx[bottom_right_tile_id]/(num_tile_columns_minus1+1)  (7-47)

sliceLastTileRowIdx=TileIdToIdx[bottom_right_tile_id]%(num_tile_columns_minus1+1)   (7-48)

LeftBoundaryPos=ColBd[sliceFirstTileColIdx]<<Ctb Log 2SizeY  (7-49)

RightBoundaryPos=((ColBd[sliceLastTileColIdx]+ColWidth[sliceLastTileColIdx])<<CtbLog 2SizeY)−1  (7-50)

TopBoundaryPos=RowBd[sliceFirstTileRowIdx]<<Ctb Log 2SizeY  (7-51)

BotBoundaryPos=((RowBd[sliceLastTileRowIdx]+RowHeight[sliceLastTileRowIdx])<<CtbLog 2SizeY)−1  (7-52)

Otherwise (slice_boundary_treated_as_pic_boundary_flag is equal toFALSE), the following applies:

LeftBoundaryPos=0  (7-53)

RightBoundaryPos=pic_width_in_luma_samples−1  (7-54)

TopBoundaryPos=0  (7-55)

BotBoundaryPos=pic_height_in_luma_samples−1  (7-56)

The derivation process for temporal luma motion vector prediction is asfollows. If yCb>>Ctb Log 2SizeY is equal to yColBr>>Ctb Log 2SizeY,yColBr is less than pic_height_in_luma_samples, and xColBr is less thanpic_width_in_luma_samples, the following applies:

The variable colCb specifies the luma coding block covering the modifiedlocation given by ((xColBr>>3)<<3, (yColBr>>3)<<3) inside the collocatedpicture specified by ColPic. The luma location (xColCb, yColCb) is setequal to the top-left sample of the collocated luma coding blockspecified by colCb relative to the top-left luma sample of thecollocated picture specified by ColPic. The derivation process forcollocated motion vectors is invoked with currCb, colCb, (xColCb,yColCb), refIdxLX, and control parameter controlParaFlag set equal to 0as inputs, and the output is assigned to mvLXCol and availableFlagLXCol.If yCb>>Ctb Log 2SizeY is equal to yColBr>>Ctb Log 2SizeY, yColBr isless than or equal to BotBoundaryPos and xColBr is less than or equal toRightBoundaryPos, the following applies. The variable colCb specifiesthe luma coding block covering the modified location given by((xColBr>>3)<<3, (yColBr>>3)<<3) inside the collocated picture specifiedby ColPic. The luma location (xColCb, yColCb) is set equal to thetop-left sample of the collocated luma coding block specified by colCbrelative to the top-left luma sample of the collocated picture specifiedby ColPic. The derivation process for collocated motion vectors isinvoked with currCb, colCb, (xColCb, yColCb), refIdxLX, and controlparameter controlParaFlag set equal to 0 as inputs, and the output isassigned to mvLXCol and availableFlagLXCol.

In some examples, the derivation process for temporal luma motion vectorprediction is as follows. If yCb>>Ctb Log 2SizeY is equal to yColBr>>CtbLog 2SizeY, yColBr is less than pic_height_in_luma_samples and xColBr isless than pic_width_in_luma_samples, the following applies. The variablecolCb specifies the luma coding block covering the modified locationgiven by ((xColBr>>3)<<3, (yColBr>>3)<<3) inside the collocated picturespecified by ColPic. The luma location (xColCb, yColCb) is set equal tothe top-left sample of the collocated luma coding block specified bycolCb relative to the top-left luma sample of the collocated picturespecified by ColPic. The derivation process for collocated motionvectors is invoked with currCb, colCb, (xColCb, yColCb), refIdxLX, andcontrol parameter controlParaFlag set equal to 0 as inputs, and theoutput is assigned to mvLXCol and availableFlagLXCol. If yCb>>Ctb Log2SizeY is equal to yColBr>>Ctb Log 2SizeY, the following applies.xColCtr=Min(xColCtr, RightBoundaryPos) and yColCtr=Min(yColCtr,BotBoundaryPos). The variable colCb specifies the luma coding blockcovering the modified location given by ((xColBr>>3)<<3, (yColBr>>3)<<3)inside the collocated picture specified by ColPic. The luma location(xColCb, yColCb) is set equal to the top-left sample of the collocatedluma coding block specified by colCb relative to the top-left lumasample of the collocated picture specified by ColPic. The derivationprocess for collocated motion vectors is invoked with currCb, colCb,(xColCb, yColCb), refIdxLX, and control parameter controlParaFlag setequal to 0 as inputs, and the output is assigned to mvLXCol andavailableFlagLXCol.

The luma sample interpolation process is as follows. The inputs to thisprocess are: a luma location in full-sample units (xIntL, yIntL); a lumalocation in fractional-sample units (xFracL, yFracL); and the lumareference sample array refPicLXL. The output of this process is apredicted luma sample value predSampleLXL. The variables shift1, shift2,shift3 are derived as follows. The variable shift1 is set equal toMin(4, BitDepthY−8) and the variable shift2 is set equal to 6 and thevariable shift3 is set equal to Max(2, 14−BitDepthY). The predicted lumasample value predSampleLXL is derived as follows. If both xFracLandyFracL are equal to 0, the value of predSampleLXL is derived as follows:

predSampleLXL=refPicLXL[xIntL][yIntL]<<shift3  (8-228)

Otherwise if xFracL is not equal to 0 and yFracL is equal to 0, thevalue of predSampleLXL is derived as follows:

predSampleLXL=(fL[xFracL,0]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL−3)][yIntL]+fL[xFracL][1]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL−2)][yIntL]+fL[xFracL][2]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL−1)][yIntL]+fL[xFracL][3]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL)][yIntL]fL[xFracL][4]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+1)][yIntL]+fL[xFracL][5]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+2)][yIntL]+fL[xFracL][6]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+3)][yIntL]+fL[xFracL][7]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+4)][yIntL])>>shift1  (8-228)

Otherwise if xFracL is equal to 0 and yFracL is not equal to 0, thevalue of predSampleLXL is derived as follows:

predSampleLXL=(fL[yFracL,0]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL−3)]+fL[yFracL][1]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL−2)]+fL[yFracL][2]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL−1)]+fL[yFracL][3]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL)]+fL[yFracL][4]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+1)]+fL[yFracL][5]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+2)]+fL[yFracL][6]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+3)]+fL[yFracL][7]*refPicLXL[xIntL][Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+4)])>>shift1  (8-228)

Otherwise if xFracL is not equal to 0 and yFracL is not equal to 0, thevalue of predSampleLXL is derived as follows. The sample array temp[n]with n=0 . . . 7, is derived as follows:

yPosL=Clip3(TopBoundaryPos,BotBoundaryPos,yIntL+n−3)  (8-228)

temp[n]=(fL[xFracL,0]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL−3)][yPosL]+fL[xFracL][1]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL2)][yPosL]+fL[xFracL][2]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL1)][yPosL]+fL[xFracL][3]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL)][yPosL]+fL[xFracL][4]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+1)][yPosL]+fL[xFracL][5]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+2)][yPosL]+fL[xFracL][6]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+3)][yPosL]+fL[xFracL][7]*refPicLXL[Clip3(LeftBoundaryPos,RightBoundaryPos,xIntL+4)][yPosL])>>shift1  (8-228)

The predicted luma sample value predSampleLXL is derived as follows:

predSampleLXL=(fL[yFracL][0]*temp[0]+fL[yFracL][1]*temp[1]+fL[yFracL][2]*temp[2]+fL[yFracL][3]*temp[3]+fL[yFracL][4]*temp[4]+fL[yFracL][5]*temp[5]+fL[yFracL][6]*temp[6]+fL[yFracL][7]*temp[7])>>shift2  (8-228)

TABLE 5 Fractional sample interpolation filter coefficients position pfL[p][0] fL[p][1] fL[p][2] fL[p][3] fL[p][4] fL[p][5] fL[p][6] fL[p][7]1 0 1 −3 63 4 −2 1 0 2 −1 2 −5 62 8 −3 1 0 3 −1 3 −8 60 13 −4 1 0 4 −1 4−10 58 17 −5 1 0 5 −1 4 −11 52 26 −8 3 −1 6 −1 3 −9 47 31 −10 4 −1 7 −14 −11 45 34 −10 4 −1 8 −1 4 −11 40 40 −11 4 −1 9 −1 4 −10 34 45 −11 4 −110 −1 4 −10 31 47 −9 3 −1 11 −1 3 −8 26 52 −11 4 −1 12 0 1 −5 17 58 −104 −1 13 0 1 −4 13 60 −8 3 −1 14 0 1 −3 8 62 −5 2 −1 15 0 1 −2 4 63 −3 10

The chroma sample interpolation process is as follows. Inputs to thisprocess are: a chroma location in full-sample units (xIntC, yIntC); achroma location in eighth fractional-sample units (xFracC, yFracC); andthe chroma reference sample array refPicLXC. Output of this process is apredicted chroma sample value predSampleLXC. The variables shift1,shift2, shift3, picWC, and picHC are derived as follows. The variableshift1 is set equal to Min(4, BitDepthC−8), the variable shift2 is setequal to 6, and the variable shift3 is set equal to Max(2,14−BitDepthC). The variable lPos, rPos, tPos and bPos are set asfollows:

lPos=LeftBoundaryPos/SubWidthC  (8-228)

rPos=(RightBoundaryPos+1)/SubWidthC  (8-228)

tPos=TopBoundaryPos/SubHeightC  (8-228)

bPos=(BotBoundaryPos+1)/SubHeightC  (8-228)

The predicted chorma sample value predSampleLXC is derived as follows.If both xFracC and yFracC are equal to 0, the value of predSampleLXC isderived as follows:

predSampleLXC=refPicLXC[xIntC][yIntC]<<shift3  (8-228)

Otherwise if xFracC is not equal to 0 and yFracC is equal to 0, thevalue of predSampleLXC is derived as follows:

predSampleLXC=(fC[xFracC][0]*refPicLXC[Clip3(lPos,rPos,xIntC−1)][yIntC]+fC[xFracC][1]*refPicLXC[Clip3(lPos,rPos,xIntC)][yIntC]+fC[xFracC][2]*refPicLXC[Clip3(lPos,rPos,xIntC+1)][yIntC]+fC[xFracC][3]*refPicLXC[Clip3(lPos,rPos,xIntC+2)][yIntC])>>shift1  (8-228)

Otherwise if xFracC is equal to 0 and yFracC is not equal to 0, thevalue of predSampleLXC is derived as follows:

redSampleLXC=(fC[yFracC][0]*refPicLXC[xIntC][Clip3(tPos,bPos,yIntC−1)]+fC[yFracC][1]*refPicLXC[xIntC][Clip3(tPos,bPos,yIntC)]+fC[yFracC][2]*refPicLXC[xIntC][Clip3(tPos,bPos,yIntC+1)]+fC[yFracC][3]*refPicLXC[xIntC][Clip3(tPos,bPos,yIntC+2)])>>shift1  (8-228)

Otherwise if xFracC is not equal to 0 and yFracC is not equal to 0, thevalue of predSampleLXC is derived as follows. The sample array temp[n]with n=0 . . . 3, is derived as follows:

yPosC=Clip3(tPos,bPos,yIntC+n−1)  (8-228)

temp[n]=(fC[xFracC][0]*refPicLXC[Clip3(lPos,rPos,xIntC−1)][yPosC]+fC[xFracC][1]*refPicLXC[Clip3(lPos,rPos,xIntC)][yPosC]+fC[xFracC][2]*refPicLXC[Clip3(lPos,rPos,xIntC+1)][yPosC]+fC[xFracC][3]*refPicLXC[Clip3(lPos,rPos,xIntC+2)][yPosC])>>shift1  (8-228)

The predicted chroma sample value predSampleLXC is derived as follows:

predSampleLXC=(fC[yFracC][0]*temp[0]+fC[yFracC][1]*temp[1]+fC[yFracC][2]*temp[2]+fC[yFracC][3]*temp[3])>>shift2  (8-228)

TABLE 6 Fractional sample interpolation filter coefficients position pfC[p]]0] fC[p][1] fC[p][2] fC[p][3] 1 −1 63 2 0 2 −2 62 4 0 3 −2 60 7 −14 −2 58 10 −2 5 −3 57 12 −2 6 −4 56 14 −2 7 −4 55 15 −2 8 −4 54 16 −2 9−5 53 18 −2 10 −6 52 20 −2 11 −6 49 24 −3 12 −6 46 28 −4 13 −5 44 29 −414 −4 42 30 −4 15 −4 39 33 −4 16 −4 36 36 −4 17 −4 33 39 −4 18 −4 30 42−4 19 −4 29 44 −5 20 −4 28 46 −6 21 −3 24 49 −6 22 −2 20 52 −6 23 −2 1853 −5 24 −2 16 54 −4 25 −2 15 55 −4 26 −2 14 56 −4 27 −2 12 57 −3 28 −210 58 −2 29 −1 7 60 −2 30 0 4 62 −2 31 0 2 63 −1

The Context-Based Adaptive Binary Arithmetic Coding (CABAC) parsingprocess for slice data is as follows. The initialization process isinvoked when starting the parsing of the CTU syntax and the CTU is thefirst CTU in a tile. Note that the start of the slice data is alsocovered by this sentence as each start of the slice data is the start ofa tile.

In another example, the CTB raster and tile scanning process is asfollows. The list ColWidth[i] for i ranging from 0 tonum_tile_columns_minus1, inclusive, specifying the width of the i-thtile column in units of CTBs, is derived as follows:

if( uniform_tile_spacing_flag )  for( i = 0; i <=num_tile_columns_minus1; i++ )   ColWidth[ i ] = ( ( i + 1 ) *PicWidthInCtbsY ) / ( num_tile_columns_minus1 + 1 ) −    ( i *PicWidthInCtbsY ) / ( num_tile_columns_minus1 + 1 ) else {  ColWidth[num_tile_columns_minus1 ] = PicWidthInCtbsY    (6-1)  for( i = 0; i <num_tile_columns_minus1; i++ ) {   ColWidth[ i ] =tile_column_width_minus1[ i ] + 1   ColWidth[ num_tile_columns_minus1 ]−= ColWidth[ i ]  } }

The list RowHeight[j] for j ranging from 0 to num_tile_rows_minus1,inclusive, specifying the height of the j-th tile row in units of CTBs,is derived as follows:

if( uniform_tile_spacing_flag )  for( j = 0; j <= num_tile_rows_minus1;j++ )   RowHeight[ j ] = ( ( j + 1) * PicHeightInCtbsY ) /   (num_tile_rows_minus1 + 1 ) −     ( j * PicHeightInCtbsY ) / (num_tile_rows_minus1 + 1) else {  RowHeight[ num_tile_rows_minus1 ] =PicHeightInCtbsY    (6-2)  for( j = 0; j < num_tile_rows_minus1; j++ ) {  RowHeight[ j ] = tile_row_height_minus1[ j ] + 1   RowHeight[num_tile_rows_minus1 ] −= RowHeight[ j ]  } }

The list ColBd[i] for i ranging from 0 to num_tile_columns_minus1+1,inclusive, specifying the location of the i-th tile column boundary inunits of CTBs, is derived as follows: for(ColBd[0]=0, i=0;i<=num_tile_columns_minus1; i++)

ColBd[i+1]=ColBd[i]+ColWidth[i]  (6-3)

The list RowBd[j] for j ranging from 0 to num_tile_rows_minus1+1,inclusive, specifying the location of the j-th tile row boundary inunits of CTBs, is derived as follows: for(RowBd[0]=0, j=0;j<=num_tile_rows_minus1; j++)

RowBd[j+1]=RowBd[j]+RowHeight[j]  (6-4)

The list CtbAddrRsToTs[ctbAddrRs] for ctbAddrRs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in CTB raster scan of a picture to a CTB address in tile scan.is derived as follows:

for( ctbAddrRs = 0; ctbAddrRs < PicSizeInCtbsY; ctbAddrRs++ ) {  tbX =ctbAddrRs % PicWidthInCtbsY  tbY = ctbAddrRs / PicWidthInCtbsY  for( i =0; i <= num_tile_columns_minus1; i++ )   if( tbX >= ColBd[ i ] )   tileX = i  for( j = 0; j <= num_tile_rows_minus1; j++ )         (6-5)   if( tbY >= RowBd[ j ] )    tileY = j  CtbAddrRsToTs[ctbAddrRs ] = 0  for( i = 0; i < tileX; i++ )   CtbAddrRsToTs[ ctbAddrRs] += RowHeight[ tileY ] * ColWidth[ i ]  for( j = 0; j < tileY; j++ )  CtbAddrRsToTs[ ctbAddrRs ] += PicWidthInCtbsY * RowHeight[ j ] CtbAddrRsToTs[ ctbAddrRs ] += ( tbY − RowBd[ tileY ] ) * ColWidth[tileX ] + tbX − ColBd[ tileX ] }

The list CtbAddrTsToRs[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a CTB address in CTB raster scan of a picture,is derived as follows:

for(ctbAddrRs=0;ctbAddrRs<PicSizeInCtbsY;ctbAddrRs++)  (6-6)

CtbAddrTsToRs[CtbAddrRsToTs[ctbAddrRs]]=ctbAddrRs

The list TileId[ctbAddrTs] for ctbAddrTs ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a CTBaddress in tile scan to a tile ID, is derived as follows:

for( j = 0, tileIdx = 0; j <= num_tile_rows_minus1; j++ )  for( i = 0; i<= num_tile_columns_minus1; i++, tileIdx++ )   for( y = RowBd[ j ]; y <RowBd[ j + 1 ]; y++ )       (6-7)    for( x = ColBd[ i ]; x < ColBd[ i +1 ]; x++ )     TileId[ CtbAddrRsToTs[ y * PicWidthInCtbsY+ x ] ] =      

 tileIdx

The list NumCtusInTile[tileIdx] for tileIdx ranging from 0 toPicSizeInCtbsY−1, inclusive, specifying the conversion from a tile indexto the number of CTUs in the tile, is derived as follows:

for(j=0,tileIdx=0;j<=num_tile_rows_minus1;j++)

for(i=0;i<=num_tile_columns_minus1;i++,tileIdx++)

NumCtusInTile[tileIdx]=ColWidth[i]*RowHeight[j]  (6-8)

The set TileIdToIdx[tileId] for a set of NumTilesInPic tileId valuesspecifying the conversion from a tile ID to a tile index and the listFirstCtbAddrTs[tileIdx] for tileIdx ranging from 0 to NumTilesInPic−1,inclusive, specifying the conversion from a tile ID to the CTB addressin tile scan of the first CTB in the tile are derived as follows:

for( ctbAddrTs = 0, tileIdx = 0, tileStartFlag = 1; ctbAddrTs <PicSizeInCtbsY; ctbAddrTs++ ) {  if( tileStartFlag ) {   TileIdToIdx[TileId[ ctbAddrTs ] ] = tileIdx   FirstCtbAddrTs[ tileIdx ] = ctbAddrTs         (6-9)   tileStartFlag = 0  }  tileEndFlag = ctbAddrTs = =PicSizeInCtbsY − 1 | | TileId[ ctbAddrTs + 1 ] != TileId[ ctbAddrTs ] if( tileEndFlag ) {   tileIdx++   tileStartFlag = 1  } }

The values of ColumnWidthInLumaSamples[i], specifying the width of thei-th tile column in units of luma samples, are set equal toColWidth[i]<<Ctb Log 2SizeY for i ranging from 0 tonum_tile_columns_minus1, inclusive. The values ofRowHeightInLumaSamples[j], specifying the height of the j-th tile row inunits of luma samples, are set equal to RowHeight[j]<<Ctb Log 2SizeY forj ranging from 0 to num_tile_rows_minus1, inclusive.

The Picture parameter set RBSP syntax is as follows.

TABLE 7 Descriptor     pic_parameter_set_rbsp( ) {      pps_pic_parameter_set_id ue(v)       pps_seq_parameter_set_idue(v)      transform_skip_enabled_flag u(1)      single_tile_in_pic_flag u(1)      if( !single_tile_in_pic_flag ) {         num_tile_columns_minus1 ue(v)           num_tile_rows_minus1ue(v)            }     

    

   

 

  

 

     if( !single_tile_in_pic_flag ) {        uniform_tile_spacing_flagu(1)       if( !uniform_tile_spacing_flag ) {      for( i = 0; i <num_tile_columns_minus1; i++ )         tile_column_width_minus1[ i ]ue(v)       for( i = 0; i < num_tile_rows_minus1; i++ )        tile_row_height_minus1 ue(v)              }    tile_boundary_treated_as_pic_boundary_flag u(1)    if(!tile_boundary_treated_as_pic_boundary_flag )        loop_filter_across_tiles_enabled_flag u(1)             }         rbsp_trailing_bits( )            }

The slice header syntax is as follows:

TABLE 8 Descriptor      slice_header( ) {     slice_pic_parameter_set_idue(v)       first_slice_in_pic_flag u(1)      single_tile_in_slice_flagu(1)     if( !first_slice_in_pic_flag ) top_left_tile_id u(v)    if(!single_tile_in_slice_flag )        bottom_right_tile_id u(v)        slice_type ue(v)       if ( slice_type != I)      log2_diff_ctu_max_bt_size ue(v)      dep_quant_enabled_flag u(1)   if( !dep_quant_enabled_flag )      sign_data_hiding_enabled_flag u(1)      all_tiles_mcts_flag u(1)          if(!tile_boundary_treated_as_pic_boundary_flag && !all_tiles_mcts_flag ) slice_boundary_treated_as_pic_boundary_flag   if(!single_tile_in_slice_flag ) {         offset_len_minus1 ue(v)   for( i= 0; i < NumTilesInSlice − 1; i++ )        entry_point_offset_minus1[ i] u(v)          }       byte_alignment( )         }

The slice header semantics are as follows. When present, the value ofthe slice header syntax element slice_pic_parameter_set_id shall be thesame in all slice headers of a coded picture. Theslice_pic_parameter_set_id specifies the value ofpps_pic_parameter_set_id for the PPS in use. The value ofslice_pic_parameterset_id shall be in the range of 0 to 63, inclusive.The first_slice_in_pic_flag is set equal to one to specify that theslice is the first slice of the picture in decoding order. Thefirst_slice_in_pic_flag is set equal to zero to specify that the sliceis not the first slice of the picture in decoding order. Thesingle_tile_in_slice_flag is set equal to one to specify that there isonly one tile in the slice. single_picture_in_pic_flag equal to 0specifies that there is more than one tile in the slice. Thetop_left_tile_id specifies the tile ID of the tile located at thetop-left corner of the slice. The length of top_left_tile_id is Ceil(Log2((num_tile_rows_minus1+1)*(num_tile_columns_minus1+1))) bits. The valueof top_left_tile_id shall not be equal to the value of top_left_tile_idof any other coded slice NAL unit of the same coded picture. When notpresent, the value of top_left_tile_id is inferred to be equal to zero.When there is more than one slice in a picture, the decoding order ofthe slices in the picture shall be in increasing value oftop_left_tile_id. The bottom_right_tile_id specifies the tile ID of thetile located at the bottom-right corner of the slice. The length ofbottom_right_tile_id is Ceil(Log2((num_tile_rows_minus1+1)*(num_tile_columns_minus1+1))) bits. When notpresent, the value of bottom_right_tile_id is inferred to be equal totop_left_tile_id. The variables NumTileRowsInSlice,NumTileColunmsInSlice, and NumTilesInSlice are derived as follows:

deltaTileIdx=TileIdToIdx[bottom_right_tile_id]−TileIdToIdx[top_left_tile_id]

NumTileRowsInSlice=(deltaTileIdx/(num_tile_columns_minus1+1))+1  (7-25)

NumTileColumnsInSlice=(deltaTileIdx % (num_tile_columns_minus1+1))+1

NumTilesInSlice=NumTileRowsInSlice*NumTileColumnsInSlice

The all_tiles_mcts_flag is set equal to one to specify that all tiles inthe slice are part of an MCTS, which only contains the tiles in theslice for the current access unit, and the MCTS boundaries (whichcollocate with the slice boundaries of the slice) are treated the sameas picture boundaries. The all_tiles_mcts_flag is set equal to zero tospecify that the above as specified by all_tiles_mcts_flag equal to 1may or may not apply. The slice_boundary_treated_as_pic_boundary_flag isset equal to one to specify that each slice boundary of the slice istreated the same as the picture boundary in the decoding process. Theslice_boudnary_treated_as_pic_boundary_flag is set equal to zero tospecify that each tile boundary may or may not be treated the same asthe picture boundary in the decoding process. When not present, thevalue of slice_boundary_treated_as_pic_boundary_flag is inferred to beequal to one. Each subset shall include all coded bits of all CTUs inthe slice that are within the same tile.

FIG. 7 is a schematic diagram of an example video coding device 700. Thevideo coding device 700 is suitable for implementing the disclosedexamples/embodiments as described herein. The video coding device 700comprises downstream ports 720, upstream ports 750, and/or transceiverunits (Tx/Rx) 710, including transmitters and/or receivers forcommunicating data upstream and/or downstream over a network. The videocoding device 700 also includes a processor 730 including a logic unitand/or central processing unit (CPU) to process the data and a memory732 for storing the data. The video coding device 700 may also compriseelectrical, optical-to-electrical (OE) components, electrical-to-optical(EO) components, and/or wireless communication components coupled to theupstream ports 750 and/or downstream ports 720 for communication of datavia electrical, optical, or wireless communication networks. The videocoding device 700 may also include input and/or output (I/O) devices 760for communicating data to and from a user. The I/O devices 760 mayinclude output devices such as a display for displaying video data,speakers for outputting audio data, etc. The I/O devices 760 may alsoinclude input devices, such as a keyboard, mouse, trackball, etc.,and/or corresponding interfaces for interacting with such outputdevices.

The processor 730 is implemented by hardware and software. The processor730 may be implemented as one or more CPU chips, cores (e.g., as amulti-core processor), field-programmable gate arrays (FPGAs),application specific integrated circuits (ASICs), and digital signalprocessors (DSPs). The processor 730 is in communication with thedownstream ports 720, Tx/Rx 710, upstream ports 750, and memory 732. Theprocessor 730 comprises a coding module 714. The coding module 714implements the disclosed embodiments described above, such as methods100, 800, and 900, which may employ a bitstream 500 and/or an image 600.The coding module 714 may also implement any other method/mechanismdescribed herein. Further, the coding module 714 may implement a codecsystem 200, an encoder 300, and/or a decoder 400. For example, thecoding module 714 can partition an image into slices, slices into tiles,tile into CTUs, CTUs into blocks, and encode the blocks when acting asan encoder. Further, the coding module 714 can implicitly signal thenumber of tiles in a slice, the number of entry point offsets for tilesin the slice, the CTU addresses of the tiles, the last CTU in a sliceand/or other data by signaling the boundaries of the slice based on thetile IDs of the first and last tiles in the slice. When acting as adecoder, the coding module 714 can reconstruct such data based on thefirst and last tiles in a slice, and hence increase coding efficiency.Hence, coding module 714 causes the video coding device 700 to provideadditional functionality and/or coding efficiency when partitioning andcoding video data. As such, the coding module 714 improves thefunctionality of the video coding device 700 as well as addressesproblems that are specific to the video coding arts. Further, the codingmodule 714 effects a transformation of the video coding device 700 to adifferent state. Alternatively, the coding module 714 can be implementedas instructions stored in the memory 732 and executed by the processor730 (e.g., as a computer program product stored on a non-transitorymedium).

The memory 732 comprises one or more memory types such as disks, tapedrives, solid-state drives, read only memory (ROM), random access memory(RAM), flash memory, ternary content-addressable memory (TCAM), staticrandom-access memory (SRAM), etc. The memory 732 may be used as anover-flow data storage device, to store programs when such programs areselected for execution, and to store instructions and data that are readduring program execution.

FIG. 8 is a flowchart of an example method 800 of encoding an image,such as image 600, into a bitstream, such as bitstream 500. Method 800may be employed by an encoder, such as a codec system 200, an encoder300, and/or a video coding device 700 when performing method 100.

Method 800 may begin when an encoder receives a video sequence includinga plurality of images and determines to encode that video sequence intoa bitstream, for example based on user input. The video sequence ispartitioned into pictures/images/frames for further partitioning priorto encoding. At step 801, an image is partitioned into a plurality ofslices. The slices are partitioned into a plurality of tiles. The tilesare partitioned into a plurality of CTUs. The CTUs are furtherpartitioned into coding blocks.

At step 803, each slice is encoded in a separate VCL NAL unit in abitstream. The slices contain tile(s), CTUs, and coding blocks. As such,the tiles, CTUs, and coding blocks of each slice are also encoded into acorresponding VCL NAL unit. The bitstream includes a plurality of VCLNAL units that include the slices from the various images in the videosequence. As discussed above, a slice includes an integer number oftiles. As such, each VCL NAL unit in the plurality of VCL NAL unitscontains a single slice of image data divided into an integer number oftiles.

It should be noted that steps 805 and 807 may occur prior to, after,and/or during step 803. Steps 805 and 807 are treated separately forclarity of discussion. At step 805, tile IDs are assigned to the tilesfor each slice. Further, addresses are assigned to the CTUs. Forexample, the addresses of the CTUs in the VCL NAL unit may be assignedbased on tile IDs corresponding to the tiles that contain the CTUs.

At step 807, a value indicating a number of the tiles in a correspondingslice, and hence in each VCL NAL unit, is encoded in the bitstream. Forexample, the number of the tiles in a VCL NAL unit may be included in anon-VCL NAL unit containing a PPS or a slice header that corresponds tothe slice. In another example, the number of tiles may be omitted fromthe bitstream as the decoder may be capable of determining the number oftiles in a VCL NAL unit based on the top-left and bottom-right tiles inthe corresponding slice (which may be signaled in the non-VCL NAL unitcontaining the slice header). Entry point offsets for the tiles are alsoencoded in the bitstream. For example, the entry point offsets for thetiles may be encoded in a slice header associated with the slice. Theentry point offsets each indicate a starting location of a correspondingtile in the VCL NAL unit. A number of entry point offsets is notexplicitly signaled in the bitstream because the number of entry pointoffsets can be determined as a value of one less than the number oftiles. In some examples, the addresses of the CTUs in the VCL NAL unitmay also be explicitly signaled in the slice header. In other examples,the addresses of the CTUs in the VCL NAL unit are omitted from thebitstream to support determination of the addresses of the CTUs at thedecoder based on a tile ID of a first tile contained in the VCL NALunit. As described above, the CTUs encoded in step 803 may not contain aflag indicating a last CTU in the VCL NAL unit. This is because thedecoder can determine the number of CTUs in the VCL NAL unit based onthe knowledge of the number of tiles in the slice. However, the VCL NALunit may be encoded to contain a padding bit immediately following alast CTU in each tile to support maintaining separation between theimage data associated with each tile.

At step 809, the bitstream is transmitted without the number of entrypoint offsets to support decoding the tiles according to an inferencethat the number of entry point offsets for the tiles is one less thanthe number of the tiles in the VCL NAL unit.

FIG. 9 is a flowchart of an example method 900 of decoding an image,such as image 600, from a bitstream, such as bitstream 500. Method 900may be employed by a decoder, such as a codec system 200, a decoder 400,and/or a video coding device 700 when performing method 100.

Method 900 may begin when a decoder begins receiving a bitstream ofcoded data representing a video sequence, for example as a result ofmethod 800. At step 901, a bitstream is received at a decoder. Thebitstream includes a plurality of VCL NAL units each containing imagedata divided into a plurality of tiles. As noted above, each slice of animage includes an integer number of tiles. Further, each slice isincluded in a separate VCL NAL unit. Accordingly, each VCL NAL unitincludes an integer number of tiles. Further, the tiles are each dividedinto a plurality of CTUs, which are further divided into a plurality ofcoding blocks.

At step 903, the decoder determines a number of the tiles in the VCL NALunit. For example, the number of the tiles in the VCL NAL unit can beobtained from a non-VCL NAL unit containing a corresponding sliceheader. In another example, the slice header may contain data indicatingthe upper-left and bottom-right tile in the slice. This data can be usedto determine the number of the tiles in the slice and hence in the VCLNAL unit. The decoder can then use the number of the tiles in the sliceto determine a number of entry point offsets for the tiles. For example,the number of entry point offsets for the tiles is one less than thenumber of the tiles in the VCL NAL unit. As described above, the entrypoint offsets each indicate a starting location of a corresponding tilein the VCL NAL unit. The number of entry point offsets may not beexplicitly signaled in the bitstream to increase compression and hencecoding efficiency.

At step 905, the decoder obtains the entry point offsets for the tilesfrom the bitstream based on the number of entry point offsets. Forexample, the entry point offsets for the tiles may be obtained from aslice header associated with the slice.

As noted above, the image data is coded as a plurality of CTUs containedin each of the tiles. Further, the addresses of the CTUs in the VCL NALunit may be assigned based on tile IDs corresponding to the tiles.Accordingly, at step 907, the decoder can determine tile IDs for thetiles and addresses for the CTUs based on the tile IDs. In someexamples, the tile IDs are explicitly signaled, for example in the PPSand/or slice header. In other examples, the decoder can determine thetile IDs based on the tile IDs of the upper-left tile and thebottom-right tile of the slice. Further, in some cases the addresses ofthe CTUs in the VCL NAL unit are explicitly signaled in the sliceheader. In other examples, the decoder may determine the addresses ofthe CTUs in the VCL NAL unit based on a tile ID of a first tilecontained in the VCL NAL unit (e.g., the top-left tile).

At step 909, the decoder decodes the tiles at the entry point offsets togenerate a reconstructed image. For example the decoder can use theentry point offsets of the tiles and the CTU addresses, to decode theCTUs, where CTU addresses are either explicitly signaled in the sliceheader or inferred based on tile ID. The decoder can then forward thereconstructed image toward a display as part of a reconstructed videosequence. In some examples, the decoder may not search for a flagindicating a last CTU in the VCL NAL unit as such a flag may be omittedfrom the VCL NAL unit. In such a case, the decoder can determine thenumber of CTUs in the VCL NAL unit based on the knowledge of the numberof tiles in the slice. In some examples, the decoder can separate tilesin a VCL NAL unit based on a padding bit immediately following a lastCTU in each tile.

FIG. 10 is a schematic diagram of an example system 1000 for coding avideo sequence of images, such as image 600, in a bitstream, such asbitstream 500. System 1000 may be implemented by an encoder and adecoder such as a codec system 200, an encoder 300, a decoder 400,and/or a video coding device 700. Further, system 1000 may be employedwhen implementing method 100, 800, and/or 900.

The system 1000 includes a video encoder 1002. The video encoder 1002comprises a partitioning module 1001 for partitioning an image into aplurality of tiles. The video encoder 1002 further comprises an encodingmodule 1003 for encoding the tiles into a bitstream in at least one VCLNAL unit, encoding a number of the tiles in the VCL NAL unit in thebitstream, and encoding entry point offsets for the tiles in thebitstream, wherein the entry point offsets each indicate a startinglocation of a corresponding tile in the VCL NAL unit, and wherein anumber of entry point offsets is not explicitly signaled in thebitstream. The video encoder 1002 further comprises a transmittingmodule 1005 for transmitting the bitstream without the number of entrypoint offsets to support decoding the tiles according to an inferencethat the number of entry point offsets for the tiles is one less thanthe number of the tiles in the VCL NAL unit. The video encoder 1002 maybe further configured to perform any of the steps of method 800.

The system 1000 also includes a video decoder 1010. The video decoder1010 comprises a receiving module 1011 for receiving a bitstreamincluding a VCL NAL unit containing image data divided into a pluralityof tiles. The video decoder 1010 further comprises a determining module1013 for determining a number of the tiles in the VCL NAL unit, anddetermining a number of entry point offsets for the tiles as one lessthan the number of the tiles in the VCL NAL unit, wherein the entrypoint offsets each indicate a starting location of a corresponding tilein the VCL NAL unit, and wherein the number of entry point offsets isnot explicitly signaled in the bitstream. The video decoder 1010 furthercomprises an obtaining module 1015 for obtaining the entry point offsetsfor the tiles based on the number of entry point offsets. The videodecoder 1010 further comprises a decoding module 1017 for decoding thetiles at the entry point offsets to generate a reconstructed image. Thevideo decoder 1010 may be further configured to perform any of the stepsof method 900.

A first component is directly coupled to a second component when thereare no intervening components, except for a line, a trace, or anothermedium between the first component and the second component. The firstcomponent is indirectly coupled to the second component when there areintervening components other than a line, a trace, or another mediumbetween the first component and the second component. The term “coupled”and its variants include both directly coupled and indirectly coupled.The use of the term “about” means a range including ±10% of thesubsequent number unless otherwise stated.

It should also be understood that the steps of the exemplary methods setforth herein are not necessarily required to be performed in the orderdescribed, and the order of the steps of such methods should beunderstood to be merely exemplary. Likewise, additional steps may beincluded in such methods, and certain steps may be omitted or combined,in methods consistent with various embodiments of the presentdisclosure.

While several embodiments have been provided in the present disclosure,it may be understood that the disclosed systems and methods might beembodied in many other specific forms without departing from the spiritor scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

In addition, techniques, systems, subsystems, and methods described andillustrated in the various embodiments as discrete or separate may becombined or integrated with other systems, components, techniques, ormethods without departing from the scope of the present disclosure.Other examples of changes, substitutions, and alterations areascertainable by one skilled in the art and may be made withoutdeparting from the spirit and scope disclosed herein.

What is claimed is:
 1. A method implemented in a decoder, the methodcomprising: receiving, by a receiver of the decoder, a bitstreamincluding a video coding layer (VCL) network abstraction layer (NAL)unit containing a slice of image data divided into a plurality of tiles;determining, by a processor of the decoder, a number of the tiles in theVCL NAL unit; determining, by the processor, a number of entry pointoffsets for the tiles as one less than the number of the tiles in theVCL NAL unit, wherein each entry point offset indicates a startinglocation of a corresponding tile in the VCL NAL unit, and wherein thenumber of entry point offsets is not explicitly signaled in thebitstream; obtaining, by the processor, entry point offsets for thetiles based on the number of entry point offsets; and decoding, by theprocessor, the tiles at the entry point offsets to generate areconstructed image.
 2. The method of claim 1, wherein the entry pointoffsets for the tiles are obtained from a slice header associated withthe slice of image data.
 3. The method of claim 1, wherein the bitstreamincludes a plurality of VCL NAL units, and wherein each VCL NAL unitcontains a single slice of image data divided into an integer number oftiles.
 4. The method of claim 1, wherein the slice of image data iscoded as a plurality of coding tree units (CTUs) contained in each ofthe tiles, and wherein addresses of the CTUs in the VCL NAL unit areassigned based on tile identifiers (IDs) corresponding to the tiles. 5.The method of claim 4, wherein decoding the tiles includes decoding theCTUs based on addresses of the CTUs in the VCL NAL unit that areexplicitly signaled in a slice header.
 6. The method of claim 4, whereindecoding the tiles includes: determining, by the processor, theaddresses of the CTUs in the VCL NAL unit based on a tile ID of a firsttile contained in the VCL NAL unit; and decoding, by the processor, theCTUs based on the addresses of the CTUs.
 7. The method of claim 4,wherein the CTUs do not contain a flag indicating a last CTU in the VCLNAL unit, and wherein the VCL NAL unit contains a padding bitimmediately following a last CTU in each tile.
 8. The method of claim 1,further comprising forwarding, by the processor, the reconstructed imagetoward a display as part of a reconstructed video sequence.
 9. A methodimplemented in an encoder, the method comprising: partitioning, by aprocessor of the encoder, an image into at least one slice andpartitioning the at least one slice into a plurality of tiles; encoding,by the processor, the tiles into a bitstream in at least one videocoding layer (VCL) network abstraction layer (NAL) unit; encoding, bythe processor, a number of the tiles in the VCL NAL unit in thebitstream; encoding, by the processor, entry point offsets for the tilesin the bitstream, wherein each entry point offset indicates a startinglocation of a corresponding tile in the VCL NAL unit, and wherein anumber of entry point offsets is not explicitly signaled in thebitstream; and transmitting, by a transmitter of the encoder, thebitstream without the number of entry point offsets to support decodingthe tiles according to an inference that the number of entry pointoffsets for the tiles is one less than the number of the tiles in theVCL NAL unit.
 10. The method of claim 9, wherein the entry point offsetsfor the tiles are encoded in a slice header associated with the slice.11. The method of claim 9, wherein the bitstream includes a plurality ofVCL NAL units, and wherein each VCL NAL unit contains a single slice ofimage divided into an integer number of tiles.
 12. The method of claim9, further comprising: partitioning the tiles into a plurality of codingtree units (CTUs); and assigning addresses of the CTUs in the VCL NALunit based on tile identifiers (IDs) corresponding to the tiles.
 13. Themethod of claim 12, further comprising explicitly signaling, in a sliceheader, the addresses of the CTUs in the VCL NAL unit.
 14. The method ofclaim 12, wherein the addresses of the CTUs in the VCL NAL unit areomitted from the bitstream to support a determination of the addressesof the CTUs at a decoder based on a tile ID of a first tile contained inthe VCL NAL unit.
 15. The method of claim 12, wherein the CTUs do notcontain a flag indicating a last CTU in the VCL NAL unit, and whereinthe VCL NAL unit contains a padding bit immediately following a last CTUin each tile.
 16. A video coding device comprising: a receiverconfigured to receive a bitstream including a video coding layer (VCL)network abstraction layer (NAL) unit containing a slice of image datadivided into a plurality of tiles; and a processor configured to:determine a number of the tiles in the VCL NAL unit; determine a numberof entry point offsets for the tiles as one less than the number of thetiles in the VCL NAL unit, wherein each entry point offset indicates astarting location of a corresponding tile in the VCL NAL unit, andwherein the number of entry point offsets is not explicitly signaled inthe bitstream; obtain entry point offsets for the tiles based on thenumber of entry point offsets; and decode the tiles at the entry pointoffsets to generate a reconstructed image.
 17. The video coding deviceof claim 16, wherein the entry point offsets for the tiles are obtainedfrom a slice header associated with the slice of image data.
 18. Thevideo coding device of claim 16, wherein the bitstream includes aplurality of VCL NAL units, and wherein each VCL NAL unit contains asingle slice of image data divided into an integer number of tiles. 19.The video coding device of claim 16, wherein the slice of image data iscoded as a plurality of coding tree units (CTUs) contained in each ofthe tiles, and wherein addresses of the CTUs in the VCL NAL unit areassigned based on tile identifiers (IDs) corresponding to the tiles. 20.The video coding device of claim 19, wherein decoding the tiles includesdecoding the CTUs based on addresses of the CTUs in the VCL NAL unitthat are explicitly signaled in a slice header.